-
Notifications
You must be signed in to change notification settings - Fork 15
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
Package name conflicts with actual python-semver module #39
Comments
+1 to this as being a major problem. I have a package with dependencies on the real I finally tracked this down to This is a general problem that is not OS specific. |
I will rename "semver" to "nodesemver" in 0.9.0 version #45 |
And rename repository to https://github.com/podhmo/python-node-semver |
Short description: this package conflicts with the official python-semver module. when both are installed there is non-deterministic behavior in terms of which order of precedence loads which module (i.e. if node-semver was installed first, then python-semver will fail because the environment will try to load the node-semver implementation)
This occurs in an Ubuntu 18.04 environment with Conan installed.
Internally we implemented a python based version script for our CI. We were using the official python-semver library. This worked as expected.
Then went about integration with our pipelines. We use Conan as a package manager tool, Conan uses this "node-semver" python package: https://github.com/conan-io/conan/blob/develop/conans/requirements.txt#L9
I propose that the package is renamed to avoid the conflicting module issue. Perhaps the created should match with the pip name of the package.
i.e. this repo is intended to install via
pip3 install node-semver
. So it should produce a module directory of something likenodesemver
.Reproduction:
start with an environment with no conan and no semver libraries
pip3 install conan
pip3 install python-semver
run python3 interpreter an enter:
This will likely fail stating the attribute "parse_version_info" does not exist (because it doesn't in this module)
Ultimately the solution should be to allow both implementations to exist in harmony on the same system.
The text was updated successfully, but these errors were encountered: