need for installation? about chiantipy HOT 7 CLOSED

An installation has multiple advantages, for example, it assures that dependencies are properly solved. For example, if chiantipy depends on matplotlib version 2, but fails with older versions - the installation will take care of it - and either warn the user or install the newer version of it dependency. The opposite is also true. Say that someone creates a package or simply uses chiantipy for a paper. This will make the dependencies easier to solved and a replication of an experiment will be possible as it will be linked to a particular version of chiantipy.

In addition, a versioning system will make easier the developer life, as users will find bugs or report usage problems that without saying which version they are using will be very hard to replicate and therefore find a solution. Version numbers - in many cases - also follows a standard (semantic versioning) that help developers and users to know whether the changes include API changes or improvements.

These are the main reasons of why I would tell the people to use versioning in their software - but when using software for science I find it critical. As without it, we won't be able to run an experiment and be confident that the results we obtain aren't different by changes in the software we depend on.

from chiantipy.

but the user should be free to just download the software and put it in their python path. I think we need to tell the user why it is better to install ChiantiPy, since, among other things, it makes life easier by checking for dependencies, but they should be able to just put it in their path. Right now they can not do it because the init.py statement for AstroPy(?) needs a specific version statement

Looking at the code, it seems I could just provide a version.py with
version._last_generated_version

from chiantipy.

of you just put the import of version in a try except block and default it to "no known version" or something.

from chiantipy.

Without installing a package, the responsibility of making sure the package can be imported is completely on the user, i.e. it is up to them to append to the system path or PYTHONPATH. This means they need to know where the source code lives and how to point it to the right interpreter. In my experience, this is the fastest way to frustrate and lose new users.

I don't think the typical user should ever have to think about how they are downloading the source code or where it is coming from. Ideally, they just run pip install ChiantiPy and it is instantly available for them to import in any script. There is no messing with paths or anything like that. Historically, problems with adding things to the system path or PYTHONPATH has been one of the biggest pain points of importing modules in Python and has largely been solved by improvements to pip and the growing use of conda and conda-forge.

I do not think we have to justify installable packages to the user. At this point, creating installable packages for PyPI and conda(-forge) is standard practice and arguably expected of any Python project of reasonable size. Ideally, all users will eventually retrieve ChiantiPy from one of these two sources. Only developers/contributors and anyone who wants the bleeding edge version would clone the source from GitHub.

That being said, none of these practices preclude anyone from cloning the source and adding either the whole ChiantiPy tree or individual functions/modules to their PYTHONPATH and using it that way. Some developers may find that useful in certain situations and have enough know-how to solve any "Module not found" issues.

However, I don't think we should encourage typical users to do this and I really don't think we should compromise the package structure to accommodate for this. This will only frustrate users at install time and make our code less readable overall and make our packaging structure less in-line with standard practices in the scientific Python community as well as the whole Python ecosystem.

from chiantipy.

I've been pointed by @lbillingham to this blog post "PYTHONPATH Considered Harmful" which explains the issue of the paths better than what I could do. (Featured in the first bit of episode 22 of pythonbytes).

Related with this, there's also this article that compares setup.py and requriements.txt - also thanks to @lbillingham.

from chiantipy.

@dpshelio I was trying to find that article. I knew I had heard about it on pythonbytes or Talk Python to Me. Thanks for the link!

from chiantipy.

@kdere Tracking the file version.py seems to break the install when using setup.py install (see all of the Travis CI jobs). A reasonable compromise might be to rename this file (e.g. static_version.py) and then use a try-except in ChiantiPy/__init__.py to use static_version.py if version.py is not present, i.e. if the user prefers to just add ChiantiPy to their path rather than installing it. That way there is no conflict between the tracked version.py and the auto-generated one.

from chiantipy.