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

Run-time requirements aren't declared #2002

Open
yurivict opened this issue Jan 24, 2025 · 4 comments
Open

Run-time requirements aren't declared #2002

yurivict opened this issue Jan 24, 2025 · 4 comments

Comments

@yurivict
Copy link

There should be one of these:

  1. dependencies section in pyproject.toml
  2. requirements section in setup.py
  3. requirements.txt file
@mattwthompson
Copy link
Member

mattwthompson commented Jan 24, 2025

They're specified in the metadata of the conda package(s)

I don't think it's necessarily a bad idea to include them in the Python config (strong preference for option 1 here) because of all of the tooling around it but given that it's not actually used in our current packaging, it's bound to fall out of sync almost immediately

@yurivict
Copy link
Author

yurivict commented Jan 25, 2025

conda support isn't sufficient in general.

When we install a FreeBSD package and some other Python package would depend on it, Python's build/install modules wouldn't have dependency information and wouldn't be able to check dependencies like they normally do with virtually all other PEP517-based Python packages.

You probably assume that everyone would just use Conda based on your recommendation, but this can't always be the case.

Python defines its own standards on how packages are built and installed, and Conda-only approach contradicts this Python standard.

@mattwthompson
Copy link
Member

@j-wags can elaborate further on why PyPI packages are not currently produced, and perhaps some of the historical details as well

@j-wags
Copy link
Member

j-wags commented Jan 26, 2025

Thanks for writing in, Yuri. We are indeed not PEP517-compliant, and we rarely get external requests to distribute on pypi (though for completeness I'll link this one, and mention that @mattwthompson internally advocated pypi releases to our advisory board, but it was voted down). I hadn't foreseen the issues this causes downstream packagers, so I appreciate you letting us know.

As Matt said, we're currently a conda shop, because that's been the only package ecosystem that has our dependencies. Now that there's an OpenMM package on pypi we're a big step closer, but there no AmberTools pypi package and no motion towards one. Without that, our critical code path (create_interchange/create_openmm_system) won't function without additional dependencies being installed outside the python requirements.

So I'm quite hesitant to put out a pypi package since new users will try it first, it will result in them getting an installation that doesn't work for the most common use cases, and many will leave without knowing about the conda option.

Staying off pypi doesn't preclude us becoming PEP517-compliant and listing deps in our package configuration. But a package manager that naively uses these deps will result in a mostly nonfunctional environment, since AmberTools won't be there.

I'm admittedly less knowledgeable than I could be here, and I'm curious to know how other packages that can't get their dependencies from pypi have navigated this situation, if you can share any examples.

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

3 participants