gradunwarp icon indicating copy to clipboard operation
gradunwarp copied to clipboard

Published 20 hours ago • verified publisher icon Washington-University

Help with packaging / PyPI distribution?

Open effigies opened this issue 1 year ago • 4 comments

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 (https://github.com/nipy/nitime/pull/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.

effigies avatar Aug 09 '23 14:08 effigies

  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.

coalsont avatar Aug 11 '23 22:08 coalsont

Alex could potentially help if we need local python expertise.

glasserm avatar Aug 11 '23 23:08 glasserm

  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.

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

Sounds good.

  1. 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.

effigies avatar Aug 23 '23 13:08 effigies

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

bpinsard avatar May 16 '24 19:05 bpinsard

@coalsont Since https://github.com/pypi/support/issues/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 avatar Oct 02 '24 14:10 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.

effigies avatar Oct 04 '24 16:10 effigies