-
Notifications
You must be signed in to change notification settings - Fork 94
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
Comments
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 |
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. |
@j-wags can elaborate further on why PyPI packages are not currently produced, and perhaps some of the historical details as well |
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 ( 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. |
There should be one of these:
dependencies
section in pyproject.tomlrequirements
section in setup.pyrequirements.txt
fileThe text was updated successfully, but these errors were encountered: