-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
setuptools changes underscore to dash for package name #2522
Comments
It looks like when Setuptools resolves the name for the metadata, it uses pkg_resources.safe_name, referencing the "[unspecified] standard distribution name" that replaces underscores with dashes. But looking at recent PEPs like PEP 508, it does look like Names are allowed to contain underscores. Probably egg_info needs to be updated to allow for underscores (and anything else allowed be the new standard). Who knows what havoc that will wreak. |
This works around: pypa/setuptools#2522 For example, when building a module which depends on 'backports_abc', fpm will currently translate that into a dependency on 'backports-abc'. When building the 'backports_abc' module, fpm will currently retain the original name. Thus, it is not possible to use fpm to meet some dependencies. Underscores should be allowed in package names, but the most important thing is to be internally consistent. If and when setuptools fixes safe_name(), then the behavior will automatically change and remain consistent. Note that this change matches both methods ok loading requirements: * for setup.py, setuptools internally calls pkg_resources.safe_name() * for requirements.txt, pkg_resources uses its own safe_anem()
This works around: pypa/setuptools#2522 For example, when building a module which depends on 'backports_abc', fpm will currently translate that into a dependency on 'backports-abc'. When building the 'backports_abc' module, fpm will currently retain the original name. Thus, it is not possible to use fpm to meet some dependencies. Underscores should be allowed in package names, but the most important thing is to be internally consistent. If and when pkg_resources fixes safe_name(), then the behavior will automatically change and remain consistent. Note that this change matches both methods ok loading requirements: * for setup.py, setuptools internally calls pkg_resources.safe_name() * for requirements.txt, pkg_resources uses its own safe_name()
This works around: pypa/setuptools#2522 For example, when building a module which depends on 'backports_abc', fpm will currently translate that into a dependency on 'backports-abc'. When building the 'backports_abc' module, fpm will currently retain the original name. Thus, it is not possible to use fpm to meet some dependencies. Underscores should be allowed in package names, but the most important thing is to be internally consistent. If and when pkg_resources fixes safe_name(), then the behavior will automatically change and remain consistent. Note that this change matches both methods ok loading requirements: * for setup.py, setuptools internally calls pkg_resources.safe_name() * for requirements.txt, pkg_resources uses its own safe_name()
This works around: pypa/setuptools#2522 For example, when building a module which depends on 'backports_abc', fpm will currently translate that into a dependency on 'backports-abc'. When building the 'backports_abc' module, fpm will currently retain the original name. Thus, it is not possible to use fpm to meet some dependencies. Underscores should be allowed in package names, but the most important thing is to be internally consistent. Monkey-patch pkg_resources.safe_name() in order to allow underscores (default for fpm) or disallow underscores, according to user specification. If and when pkg_resources fixes safe_name(), then the behavior of fpm will remain the same. Note that this change matches both methods of loading requirements: * for setup.py, setuptools internally calls pkg_resources.safe_name() * for requirements.txt, pkg_resources uses its own safe_name()
This works around: pypa/setuptools#2522 For example, when building a module which depends on 'backports_abc', fpm will currently translate that into a dependency on 'backports-abc'. When building the 'backports_abc' module, fpm will currently retain the original name. Thus, it is not possible to use fpm to meet some dependencies. Underscores should be allowed in package names, but the most important thing is to be internally consistent. Monkey-patch pkg_resources.safe_name() in order to allow underscores (default for fpm) or disallow underscores, according to user specification. If and when pkg_resources fixes safe_name(), then the behavior of fpm will remain the same. Note that this change matches both methods of loading requirements: * for setup.py, setuptools internally calls pkg_resources.safe_name() * for requirements.txt, pkg_resources uses its own safe_name()
This works around: pypa/setuptools#2522 For example, when building a module which depends on 'backports_abc', fpm will currently translate that into a dependency on 'backports-abc'. When building the 'backports_abc' module, fpm will currently retain the original name. Thus, it is not possible to use fpm to meet some dependencies. Underscores should be allowed in package names, but the most important thing is to be internally consistent. Monkey-patch pkg_resources.safe_name() in order to allow underscores (default for fpm) or disallow underscores, according to user specification. If and when pkg_resources fixes safe_name(), then the behavior of fpm will remain the same. Note that this change matches both methods of loading requirements: * for setup.py, setuptools internally calls pkg_resources.safe_name() * for requirements.txt, pkg_resources uses its own safe_name()
This is still an issue. |
This is still an issue for me as well |
I can confirm that with #4159, the issue is addressed:
|
Releasing as v69.0.3. |
Thank you! |
In `pylint_checkers/setup.py` we define the package name as `qute_pylint`. When setuptools was creating the egg (or wheel?) it was sanitizing the package name replacing all problematic chars, including underscore, with a hyphen (-). So the output of `pip freeze`, among other things, have the name with a hyphen: `qute-pylint`. This was fixed in setuptools so underscores are no longer sanitized: pypa/setuptools#2522 Change the regex to include both just in case someone is running it with the old setuptools or something. Also because I'm not able to reproduce the hyphen version of the name locally, not sure why. Maybe it depends on your python or importlib version too?
Just a heads up: we were accidentally relying on underscores becoming hyphens, I suspect other projects will hit this as well 🙂 |
Open questions: - ~~why did tests start failing this weekend? (best guess is setuptools 69.03 on Dec 23rd)~~ - ~~why does this fix the failures?~~ - would this be a breaking change? I'm hopeful that it's not, because the package is already published as dagster-webserver https://pypi.org/project/dagster-webserver/ Edit: the first two are answered by pypa/setuptools#2522 (comment): setuptools change how they handle hyphens vs underscores This makes the two required changes to get the build green (these two are special because of the underscore packages, they're the ones that are relied on in tests). In general we should make it a pattern to make package names use hyphens and match their directory name to avoid confusion.
Open questions: - ~~why did tests start failing this weekend? (best guess is setuptools 69.03 on Dec 23rd)~~ - ~~why does this fix the failures?~~ - would this be a breaking change? I'm hopeful that it's not, because the package is already published as dagster-webserver https://pypi.org/project/dagster-webserver/ Edit: the first two are answered by pypa/setuptools#2522 (comment): setuptools change how they handle hyphens vs underscores This makes the two required changes to get the build green (these two are special because of the underscore packages, they're the ones that are relied on in tests). In general we should make it a pattern to make package names use hyphens and match their directory name to avoid confusion.
Build was checking metadata in its test suite, but happy to adapt to this. By the way, I think this affects SDist naming (SDist names should be normalized, but setuptools doesn't seem to do that). We got a report of an SDist being made with spaces in the name, which is invalid. I'm suspecting this change might be related. # setup.cfg
[metadata]
name = This is not cool
version = 0.0.1 $ touch pyproject.toml
$ pipx run build .
...
Successfully built This is not cool-0.0.1.tar.gz and This_is_not_cool-0.0.1-py3-none-any.whl I believe before this change, you'd have made |
After I pip install cx_oracle, I use python -m pip show cx_oracle command and it shows the package name is cx-Oracle
After discussed with cx_Oracle's author, it shows setuptools changed the underscore to dash for the package name. Is that an issue for setuptools or is there any way to stop this auto-conversion? Thanks.
setup.cfg for cx_Oracle
[metadata]
name = cx_Oracle
PKG-INFO for cx_Oracle
Metadata-Version: 2.1
Name: cx-Oracle
setup.py used in cx_Oracel
setup the extension
extension = setuptools.Extension(
name = "cx_Oracle",
include_dirs = includeDirs,
extra_compile_args = extraCompileArgs,
define_macros = [("CXO_BUILD_VERSION", BUILD_VERSION)],
extra_link_args = extraLinkArgs,
sources = sources + dpiSources,
depends = depends,
libraries = libraries,
library_dirs = libraryDirs)
The text was updated successfully, but these errors were encountered: