Instaling by pip

[raminsalmas]

Hi,

pip install https://github.com/autonlab/auton-survival.git - doesn't work for me.

Looking for your advice.

Thanks.

[chiragnagpal]

Hi Ramin

Given that the package is currently developed primarily by research students without much bandwidth for propoer maintenance, we decided to not support pip installation, atleast for now.. this might change in the future depending on if we get enough extra hands to help with that.

As of now, the best way to use auton-survival is to git clone the repo to your local machine and add the folder to your PYTHONPATH. this can be done somewhat easily by using sys

import sys
sys.path.append()

[AND2797]

If this is something of interest, I'm happy to take a crack at it?

[ecotner]

I have been testing this package out recently and was able to install it with pip by creating a pyproject.toml in the repo root directory so it could be installed using setuptools:

[project]
name = "auton_survival"
version = "1.0.0"
description = "the auton-survival package"
license = {file = "LICENSE"}
readme = "README.md"
dependencies = [
    "torch>=1.0.0",
    "numpy>=1.16.5",
    "pandas>=1.0.0",
    "tqdm>=4.0.0",
    "scikit-learn>=0.18",
    "torchvision>=0.7.0",
    "scikit-survival>=0.15.0",
    "lifelines>=0.26.4",
]

[build-system]
requires = [
    "setuptools",
    "wheel",
]

[tool.setuptools]
packages = ["auton_survival"]

Had no trouble installing and using things after that with pip install -q -e ~/auton-survival. With this approach you guys could get rid of your requirements.txt and just stick the dependencies in this file too. Here's some of the relevant documentation if you're interested in learning more. Longer-term, I'd suggest you guys use a build tool like poetry which manages dependencies, installations, virtual environments, and can even push to PyPI (so people can do pip installs without cloning the repo).

[matteo4diani]

@IvanUniTO citing from @ecotner 's comment:

Longer-term, I'd suggest you guys use a build tool like poetry which manages dependencies, installations, virtual environments, and can even push to PyPI (so people can do pip installs without cloning the repo).

You are not bound to use poetry to manage your dependencies/envs, it's just our (proposed) build back-end.
The final objective is to publish the package to PyPI and set up a robust CI-CD pipeline: poetry is the industry standard for this kind of job, other internal and external tools are sadly lagging behind in terms of features and documentation.

With the "poetry stuff" you can easily install via pip as a Version Control System dependency without having to git clone the repo every time, moreover the dependency will be updated automatically when you pip install --upgrade.

If you are interested in trying it out, conda can easily interface with pip and VCS dependencies, see this StackOverflow thread.

Also, since you are referencing changes made in a PR, it would be better to comment on the PR with your opinions and suggestions or open a discussion: #117 .

[IvanUniTO]

Hi Matteo First, sorry to bother you. iI wrote my comments as reminders to myself in my fork of your repo. I was not aware you were going to be notified. My knowledge of github is not much. I know i am not forced to use poetry. In fact i am using conda in my projects and I decided to repackage auton in a way that is suitable to them. in the end i did it, on my fork, using flit and specifying the original boundaries from requirements.txt. Very minimal and unobtrusive, once I understood the crazy world that python packaging is now (14 tools to do the same things!!) As I said, I did not comment on issues nor did pull requests because I thought that my comments and work were local to my fork and did not bother others. About "poetry stuff": i do not like poetry. It is opinionated, it does not comply to the latest PEPs on packaging, it reinvents the wheel by implementing its own solver instead of using a solid one (e.g. libmamba, that builds on opensuse zypper code base IIRC), but that is matter of personal taste and workflow. This is why I did not think about doing pull reqs. Even if it would be nice if auton-survival author will merge at least one of the pyproject.toml proposals around ;) Will stay with conda, even if PDM shows potential and can partially interoperate with conda. All the best, Ivan Il giorno mar 18 lug 2023 alle ore 10:57 Matteo Fordiani < ***@***.***> ha scritto:

…

@IvanUniTO <https://github.com/IvanUniTO> citing from @ecotner <https://github.com/ecotner> 's comment: Longer-term, I'd suggest you guys use a build tool like poetry <https://python-poetry.org/> which manages dependencies, installations, virtual environments, and can even push to PyPI *(so people can do pip installs without cloning the repo)*. You are not bound to use poetry to manage your dependencies/envs, it's just our (proposed) build back-end. The final objective is to publish the package to PyPI and set up a robust CI-CD pipeline: poetry is the industry standard for this kind of job, other internal and external tools are sadly lagging behind in terms of features and documentation. With the "poetry stuff" you can easily install via pip as a Version Control System dependency without having to git clone the repo every time, moreover the dependency will be updated automatically when you pip install --upgrade. If you are interested in trying it out, conda can easily interface with pip and VCS dependencies, see this StackOverflow thread <https://stackoverflow.com/questions/19042389/conda-installing-upgrading-directly-from-github> . Also, since you are referencing changes made in a PR, it would be better to comment on the PR with your opinions and suggestions or open a discussion: #117 <#117> . — Reply to this email directly, view it on GitHub <#87 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6LN7MVBAHKCFUCTA4UFI73XQZFXFANCNFSM5ZYSCZZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Ivan Rossi, Ph. D. Dept. Medical Sciences - UniTO Via Santena, 19 - 10126 Torino, Italy

[matteo4diani]

@IvanUniTO No bother at all! I just want to ensure that all voices are heard since this is a scientific tool and users may prefer a different approach VS traditional SWE projects, thus I invited you to speak out on the PR or here on this issue, and thanks for doing it btw.
I guess your stance on poetry proves my concern 😁

Regarding poetry breaking PEP standards, I see where you're coming from, and I strongly prefer the standards-oriented approach taken by PDM, although it isn't mature yet to support a small team that wants to delegate the hard stuff away.