Help with packaging / PyPI distribution?

[effigies]

Hi folks. I have an interest in this package being distributed on PyPI, ideally as a binary wheel. This would speed up installation in all cases, and permit installation in minimal environments like Docker images that lack C compilers.

I recently spent some time with nitime (nipy/nitime#199) setting up CI infrastructure to build wheels for a variety of operating systems and architectures; with experience gained there, this would be quite a quick process here. (If #9 works out, then this would become a pure Python package, making it even simpler and faster.)

Some questions:

1. Any interest in distributing on PyPI?
2. Would you be willing to drop the +hcp local version segment? Looking at the network graph, this has become the de facto authoritative repository.
3. Do you intend to continue supporting Python 2 with future releases? What is the lowest Python 3.x you would want to support? (Python 3.8 is now the oldest maintained Python minor release.)

Assuming 1+2 are "yes", I can submit a pull request or two. If not, please feel free to close this.

[coalsont]

1. I don't see the downside, manual installation would still work, right?
2. I don't have a strong objection, as our version numbering hasn't overlapped for a while.
3. I don't have a reason to break old python support, particularly when we aren't adding features.

I haven't learned much python yet, and we don't really have someone in charge of this package.

[glasserm]

Alex could potentially help if we need local python expertise.

[effigies]

1. I don't see the downside, manual installation would still work, right?

It should. I will add CI to make sure that it continues to work.

2. I don't have a strong objection, as our version numbering hasn't overlapped for a while.

Sounds good.

3. I don't have a reason to break old python support, particularly when we aren't adding features.

The issue is less with breaking support (I can leave it compatible) so much as building and testing is harder, as CI tools are dropping support for end-of-life versions. The upshot is that wheels will only be available for newer Python versions, but that's not a regression.

[bpinsard]

Is there a sensible way in that packaging process to get the gradunwarp module to have a __version__ attribute?

[effigies]

@coalsont Since pypi/support#3455 seems delayed indefinitely, I'm forking this to nipy/gradunwarp and will push nipy-gradunwarp wheels for the last couple of versions so that people have something they can install without a C compiler. That will leave the namespace open for this repo to be canonical if PyPI ever releases the name.

[effigies]

• https://github.com/nipy/gradunwarp/releases/tag/nipy-1.2.2
• https://pypi.org/project/nipy-gradunwarp/1.2.2/

Trying to build and publish wheels for 1.2.1 wasn't worth it.