VERSION handling in setup.py breaks some automatic tools

[ggirelli]

Hi there! While waiting for the new release (my ability to use the package really depends on #33 ) I tried to use my dependency manager (I use poetry) to add nd2reader current master branch version directly from git.

As most dependency managers do not actually execute the setup.py file, having the version flag as a constant in the __init__.py file breaks it.

I understand that having the version flag value in a single position simplifies the routine of releasing a new package version, but do you think this could be dropped in the future, to increase compatibility with this kind of tools?

I made a temporary fork with version flag set to 3.2.3.post1 that works nicely here: ggirelli/nd2reader.

[rbnvrw]

Regarding the release: there seem to be a few problems in parsing files that may or may not originate from #40, see #46, #38 and your comment in #31 (comment) First these things have to be fixed - I hope I'll have some time to look into this.

I am not familiar with poetry, but exposing a __version__ attribute in __init__.py is common practice AFAIK. How does it break poetry?

Before changing this, we should have a better alternative versioning method. Do you have a proposal?

I saw this (a PKG-INFO file) https://www.python.org/dev/peps/pep-0566/ and the approach taken by poetry: a pyproject.toml file https://www.python.org/dev/peps/pep-0621/

Do you have any insights into which approach would be preferred?

[ggirelli]

Regarding the release: there seem to be a few problems in parsing files that may or may not originate from #40, see #46, #38 and your comment in #31 (comment) First these things have to be fixed - I hope I'll have some time to look into this.

Yes, apologies. I planned to have a look at this but I am currently focused on wrapping up things for my thesis defence :)
I believe the issue is due to the fix for stretched file parsing. I believe the best approach here would be to comment that part of the code and work on it on a separate fork/branch.

I am not familiar with poetry, but exposing a version attribute in init.py is common practice AFAIK. How does it break poetry?

Once the package is built and release, it is not a problem. The issue arises when trying to install from git.

Before changing this, we should have a better alternative versioning method. Do you have a proposal?

My favorite approach, which I am using in my packages, is to have the version specified in the pyproject.toml file and as a serviceable variable in a const.py module or in init.py. Still, I completely understand that having the version tag in a single location is ideal. You can find a nice conversation on the topic here where they agree that placing the version tag only in the setup.py or pyproject.toml is the best solution when placing the following code in the main module __init__.py file:

from importlib.metadata import version, PackageNotFoundError

try:
    __version__ = version(__name__)
except PackageNotFoundError:
    pass

[rbnvrw]

Hi @ggirelli I've implemented your fix, let me know if it works, otherwise please reopen.