-
Notifications
You must be signed in to change notification settings - Fork 168
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
Cannot install recently created source distributions. #647
Comments
To reproduce this, I have created a small namespace package: I have uploaded version 1.0.0 to PyPI, with only a source distribution: Wait a minute, the filename there is
So yet another mystery: why does Let's not get side tracked by that. I create a source dist manually, with underscore, and upload it with So now this
But when I edit it to use 1.0.1 it fails:
So now it should be reproducible. For completeness sake, this buildout uses Python 3.11.8 on Mac OS 14.4.1, and these package versions in the venv:
|
Interesting difference: 1. Executing the build module:
So underscore. 2. Using ProjectBuilder:This is how
So with dots. DifferenceAha, a difference is that We can run build without isolation:
We have a dot here now. So the version of setuptools matters. Without isolation, you presumably get the latest, which now is 69.5.1. With that, both methods produce underscores.
The That issue has an informative comment about project names to give some background on why it is tricky for setuptools to do the right thing, and there are always compromises. 69.3.0 was actually yanked from PyPI, but that was for a different reason, to do with normalisation of version numbers. Latest 69.5.1 has the (for us) problematic code. Note that the |
Note that wheel names still have dots, but that may change. More reading: pypa/setuptools#3777 Anyway, after all that, the point is: Buildout should be able to install source distributions (and wheels) that have underscores instead of dots in the filename. |
We also have been bitten by this problem, see zopefoundation/zope.interface#298 |
I have just released Plone 6.0.11. Installing it with Buildout gives an error:
When you follow the PyPI link, the last two releases are this:
plone.app.locales-6.0.20.tar.gz
plone_app_locales-6.0.21.tar.gz
Version 6.0.20 from January (included in Plone 6.0.10) can be installed fine.
Version 6.0.21, released earlier this week, cannot.
The difference is underscores in the filename instead of dots.
A
pip install
worked fine.I have fixed it by uploading a wheel, which should have been done anyway, and then it works. The wheel filename is
plone.app.locales-6.0.21-py3-none-any.whl
, so with dots, which apparently makes it work.plone.app.locales
was released by someone else, but how about packages I released as Plone release manager? Look atplone.base
and you see the same. In March I releasedplone.base-1.3.0.tar.gz
, and this weekplone_base-1.4.0.tar.gz
.Why is there a difference in the name? Not sure. I use
zest.releaser
to create releases, usually with a source checkout from the master branch as I am one of the developers of this tool. During release, this basically callspython -m build .
This uses thebuild
package. Let's try a bit in a checkout ofplone.base
. Note that this has apyproject.toml
which since January defines:That may influence things. Let's try to build stuff:
I thought I had seen today with an earlier
build
version that the source tarball did contain only dots, but I cannot reproduce that, at least not with this package, also not when I remove thebuild-system
frompyproject.toml
.So, I don't know why the filename is suddenly with underscores, but I found PEPs that say this is how it should be:
-_.
characters (HYPHEN-MINUS, LOW LINE and FULL STOP) should be replaced with_
(LOW LINE), and uppercase characters should be replaced with corresponding lowercase ones."Interestingly the wheel filename does not follow this convention.
But apparently Buildout should be able to install source distribution filenames with underscores, but currently this fails.
The text was updated successfully, but these errors were encountered: