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

replace egg= with pkg= #1265

Closed
qwcode opened this issue Oct 28, 2013 · 13 comments
Closed

replace egg= with pkg= #1265

qwcode opened this issue Oct 28, 2013 · 13 comments
Labels
auto-locked Outdated issues that have been locked by automation type: enhancement Improvements to functionality

Comments

@qwcode
Copy link
Contributor

qwcode commented Oct 28, 2013

With the demise of eggs, the "egg=" url fragment syntax is only becoming more obscure.

We could start supporting both "egg=" and a newer "pkg=" format, then eventually deprecate, then remove support for "egg="

Ideally, we'd do this in conjunction with setuptools.

@dstufft
Copy link
Member

dstufft commented Oct 28, 2013

+10000

@jezdez
Copy link
Member

jezdez commented Oct 29, 2013

Hah, yeah! +1

@qwcode
Copy link
Contributor Author

qwcode commented Nov 4, 2013

or better, maybe we can just get rid of it, see #1289

@merwok
Copy link

merwok commented Mar 17, 2014

The Python docs tend to use “pkg” for “package”, i.e. a module that contains modules. Using it to mean package/distribution/project name could be ambiguous.

@qwcode
Copy link
Contributor Author

qwcode commented Mar 17, 2014

@merwok it's intending to be consistent with "package meaning #2"
http://packaging.python.org/en/latest/glossary.html#term-package-meaning-2

I gave in a while back, and let the PUG have 2 meanings for "package".
It fits with the state of our language.

although #req= might be a better choice. short for "requirement"

@Ivoz
Copy link
Contributor

Ivoz commented Mar 18, 2014

I wouldn't mind #dist= even though its 33% more characters, but weren't we wondering about removing the need for #egg= completely?

@qwcode
Copy link
Contributor Author

qwcode commented Mar 18, 2014

#dist= is good too. yes, removing it all together (#1289) is a possibility, but in working on a virtualenv puppet module recently, having an identifier in the requirement line for vcs urls (even if pip itself ended up not relying on it) seemed necesary

@nedbat
Copy link

nedbat commented Oct 31, 2015

I would recommend #name=, since the string there has to be the same as setup(name=...).

@xavfernandez
Copy link
Member

I like #name= also, with maybe a version= part to solve #1249 issue.
Both could be optional, and pip would only check during the install that those provided information match the reality.

@qwcode
Copy link
Contributor Author

qwcode commented Dec 3, 2015

thinking it makes since to close this as no fix considering the approval of PEP508.

PEP508 paves the way for pip to migrate to the direct reference syntax for VCS urls (https://www.python.org/dev/peps/pep-0440/#direct-references)

i.e, this: NAME @ URL
not this: URL#egg=NAME

one detail left hanging though is the use of the URL#egg=name-version format, which I'm not sure if pip has any logic for anymore?

@xavfernandez
Copy link
Member

one detail left hanging though is the use of the URL#egg=name-version format, which I'm not sure if pip has any logic for anymore?

I think that pip currently drops it https://github.com/pypa/pip/blob/69d9044/pip/req/req_install.py#L1056-L1065

I agree this could be closed.

@pradyunsg
Copy link
Member

If everyone thinks this is resolved - can we please close this? ^.^

@xavfernandez
Copy link
Member

xavfernandez commented May 16, 2017

Yup, #pkg= is unlikely to happen as the new format is now based on PEP-508 and the pkg_name @ url syntax.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation type: enhancement Improvements to functionality
Projects
None yet
Development

No branches or pull requests

8 participants