Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help with packaging / PyPI distribution? #10

Open
effigies opened this issue Aug 9, 2023 · 4 comments
Open

Help with packaging / PyPI distribution? #10

effigies opened this issue Aug 9, 2023 · 4 comments

Comments

@effigies
Copy link

effigies commented Aug 9, 2023

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
Copy link
Member

  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
Copy link

Alex could potentially help if we need local python expertise.

@effigies
Copy link
Author

  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.

@bpinsard
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants