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

Script generation code for wheels #1251

Merged
merged 3 commits into from Nov 1, 2013

Conversation

Projects
None yet
4 participants
@pfmoore
Member

pfmoore commented Oct 23, 2013

No description provided.

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Oct 24, 2013

Contributor

to be clear, this is "DO NOT MERGE" just due to wanting review, or is their another dependency that needs to be handled? or maybe that you didn't add any tests? : )

Contributor

qwcode commented Oct 24, 2013

to be clear, this is "DO NOT MERGE" just due to wanting review, or is their another dependency that needs to be handled? or maybe that you didn't add any tests? : )

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Oct 24, 2013

Member

He's carrying a patch against distlib inside it.

Member

dstufft commented Oct 24, 2013

He's carrying a patch against distlib inside it.

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode
Contributor

qwcode commented Oct 24, 2013

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 24, 2013

Member

Also, I'll collapse out the "fixing yet another typo" commits before submitting a final PR.

Member

pfmoore commented Oct 24, 2013

Also, I'll collapse out the "fixing yet another typo" commits before submitting a final PR.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 24, 2013

Member

I think this is now functionally complete. I need to do some manual testing (in addition to the test suite additions I've included) and some refactoring for maintainability/simplification. Then, once Vinay releases a fixed version of distlib, this should be good to go.

One point worth making is that with this patch, "pip install XX" does something subtly different to "pip wheel XX; pip install " in that the former will install setuptools style wrappers and the latter will install distlib style wrappers. Personally, I'm happy with this but it may cause comments.

Member

pfmoore commented Oct 24, 2013

I think this is now functionally complete. I need to do some manual testing (in addition to the test suite additions I've included) and some refactoring for maintainability/simplification. Then, once Vinay releases a fixed version of distlib, this should be good to go.

One point worth making is that with this patch, "pip install XX" does something subtly different to "pip wheel XX; pip install " in that the former will install setuptools style wrappers and the latter will install distlib style wrappers. Personally, I'm happy with this but it may cause comments.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Oct 24, 2013

Member

Do you mean pip install when it installs from a source distribution, or pip install will always install setuptools style wrappers and only wheels made by pip wheel won't?

Member

dstufft commented Oct 24, 2013

Do you mean pip install when it installs from a source distribution, or pip install will always install setuptools style wrappers and only wheels made by pip wheel won't?

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Oct 24, 2013

Member

Looking at the code it looks like the answer is wheels will always generate, sdist will always setuptools.

I think that's OK. We might want to switch to always generating even for sdists for consistency sake, but I think that we don't need to hold up this PR for that.

Member

dstufft commented Oct 24, 2013

Looking at the code it looks like the answer is wheels will always generate, sdist will always setuptools.

I think that's OK. We might want to switch to always generating even for sdists for consistency sake, but I think that we don't need to hold up this PR for that.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 24, 2013

Member

Yep, @dstufft got it right. I don't even know how we would alter the behaviour on sdists, as that is done by setuptools and not by pip. I think we have to live with the difference until sdist 2.0 and always installing via wheels becomes the standard.

Member

pfmoore commented Oct 24, 2013

Yep, @dstufft got it right. I don't even know how we would alter the behaviour on sdists, as that is done by setuptools and not by pip. I think we have to live with the difference until sdist 2.0 and always installing via wheels becomes the standard.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Oct 26, 2013

Member

We should special case the easy_install wheel as well. Namely easy_install and easy_install-X.Y needs to be created.

Member

dstufft commented Oct 26, 2013

We should special case the easy_install wheel as well. Namely easy_install and easy_install-X.Y needs to be created.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 26, 2013

Member

Hmm. OK, I guess. But only because setuptools is a prerequisite of pip, and only as a short-term fix. This needs fixing properly in metadata so that projects can specify versioned executables at source.

I know you know this, I just want it on record. Projects other than pip and setuptools will just have to put up with needing separate wheels for each Python version until this is solved properly (even though that makes wheels less attractive for them in the short term).

Member

pfmoore commented Oct 26, 2013

Hmm. OK, I guess. But only because setuptools is a prerequisite of pip, and only as a short-term fix. This needs fixing properly in metadata so that projects can specify versioned executables at source.

I know you know this, I just want it on record. Projects other than pip and setuptools will just have to put up with needing separate wheels for each Python version until this is solved properly (even though that makes wheels less attractive for them in the short term).

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Oct 26, 2013

Member

Yup agreed. The only reason I think setuptools should be special cased is because it makes it possible to install pip + dependencies entirely from Wheel. Which makes PEP453 easier/better. Somewhat selfish but I think it'll be better that way.

https://github.com/dstufft/cpython/compare/ensurepip FWIW

Member

dstufft commented Oct 26, 2013

Yup agreed. The only reason I think setuptools should be special cased is because it makes it possible to install pip + dependencies entirely from Wheel. Which makes PEP453 easier/better. Somewhat selfish but I think it'll be better that way.

https://github.com/dstufft/cpython/compare/ensurepip FWIW

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 26, 2013

Member

Just to be clear here: we want the following commands to be available (for Python 3.4, for example):

pip, pip3, pip-3.4
easy_install, easy_install-3.4

Note that the X.Y version has a dash, and the X version does not.That is distlib behaviour that I can't control (we'd need to get distlib changed if we wanted something different). And note that there is no easy_install3, because that's what the setuptools setup.py does.

BTW, setuptools' setup.py has the following:

# Gentoo distributions manage the python-version-specific scripts themselves,
# so they define an environment variable to suppress the creation of the
# version-specific scripts.
if os.environ.get("SETUPTOOLS_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT") in (None, "", "0") and \
    os.environ.get("DISTRIBUTE_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT") in (None, "", "0"):
    console_scripts.append("easy_install-%s = setuptools.command.easy_install:main" % sys.version[:3])

That's not going to be respected when we install from a wheel - I assume that's OK.

Member

pfmoore commented Oct 26, 2013

Just to be clear here: we want the following commands to be available (for Python 3.4, for example):

pip, pip3, pip-3.4
easy_install, easy_install-3.4

Note that the X.Y version has a dash, and the X version does not.That is distlib behaviour that I can't control (we'd need to get distlib changed if we wanted something different). And note that there is no easy_install3, because that's what the setuptools setup.py does.

BTW, setuptools' setup.py has the following:

# Gentoo distributions manage the python-version-specific scripts themselves,
# so they define an environment variable to suppress the creation of the
# version-specific scripts.
if os.environ.get("SETUPTOOLS_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT") in (None, "", "0") and \
    os.environ.get("DISTRIBUTE_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT") in (None, "", "0"):
    console_scripts.append("easy_install-%s = setuptools.command.easy_install:main" % sys.version[:3])

That's not going to be respected when we install from a wheel - I assume that's OK.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Oct 26, 2013

Member

It would be really nice to make that pip, pip3, pip3.4, easy_install, and easy_install-3.4.

Instead of variants could we just tell distlib that these are unrelated commands and not use the variants portion of distlib? Alternatively we could seea bout getting Vinay to make it customizable how the interpolation happens.

Member

dstufft commented Oct 26, 2013

It would be really nice to make that pip, pip3, pip3.4, easy_install, and easy_install-3.4.

Instead of variants could we just tell distlib that these are unrelated commands and not use the variants portion of distlib? Alternatively we could seea bout getting Vinay to make it customizable how the interpolation happens.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Oct 26, 2013

Member

Also yes, that's fine.

Member

dstufft commented Oct 26, 2013

Also yes, that's fine.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 26, 2013

Member

I guess I could do that.

By the way, as things stand, I'm assuming that pip and setuptools will be updated to only include "pip" and "easy_install" entry points, and not any versioned ones (that could be the wrong versions).

If that's not the case, I'd need to deliberately ignore a broader class of entry points (pip, pipN, pipN.M, easy_install, easy_install-N.M) and that gets both messy and fragile. But on the other hand, not including versioned entry points makes installation from sdist omit them.

There seem to be a number of options here:

  1. Accept the inconsistency and make install from wheel the supported approach, with install from sdist simply documented as not including versioned entry points.
  2. Hand-edit the wheels we create for pip/setuptools (at least the ones included in ensurepip and virtualenv) to remove the versioned entry points.
  3. Have pip install from wheel ignore versioned pip and easy_install entry points in the metadata as well as generating the versioned ones we want.

I'm against (3) to be honest, not just because it makes life harder for me but also because it potentially creates transition issues when we do move this stuff to metadata. And my brain isn't up to working out what those consequences would be at the moment...

Member

pfmoore commented Oct 26, 2013

I guess I could do that.

By the way, as things stand, I'm assuming that pip and setuptools will be updated to only include "pip" and "easy_install" entry points, and not any versioned ones (that could be the wrong versions).

If that's not the case, I'd need to deliberately ignore a broader class of entry points (pip, pipN, pipN.M, easy_install, easy_install-N.M) and that gets both messy and fragile. But on the other hand, not including versioned entry points makes installation from sdist omit them.

There seem to be a number of options here:

  1. Accept the inconsistency and make install from wheel the supported approach, with install from sdist simply documented as not including versioned entry points.
  2. Hand-edit the wheels we create for pip/setuptools (at least the ones included in ensurepip and virtualenv) to remove the versioned entry points.
  3. Have pip install from wheel ignore versioned pip and easy_install entry points in the metadata as well as generating the versioned ones we want.

I'm against (3) to be honest, not just because it makes life harder for me but also because it potentially creates transition issues when we do move this stuff to metadata. And my brain isn't up to working out what those consequences would be at the moment...

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 26, 2013

Member

Just pushed a version that special-cases easy_install as well, and ignores any entry points matching 'pip(\d(.\d)?)?$' or 'easy_install(-\d.\d)?$'. Well, I would have, but github seems to be playing up. Will try to do so tomorrow.

Member

pfmoore commented Oct 26, 2013

Just pushed a version that special-cases easy_install as well, and ignores any entry points matching 'pip(\d(.\d)?)?$' or 'easy_install(-\d.\d)?$'. Well, I would have, but github seems to be playing up. Will try to do so tomorrow.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 27, 2013

Member

OK. IMO, this is ready to go. Things I need to do/happen:

  1. The distlib fix is released (@vsajip) and vendored into pip (me).
  2. I rebase/collapse this set of changes into a single PR, excluding the distlib and test fixes that are covered separately. Any suggestions on git incantations to do this would be gratefully accepted, otherwise, I'll probably just copy the various files and hack it using diff.

I'll leave it now till we get a new distlib release.

If anyone can think of anything I've forgotten, let me know.

Member

pfmoore commented Oct 27, 2013

OK. IMO, this is ready to go. Things I need to do/happen:

  1. The distlib fix is released (@vsajip) and vendored into pip (me).
  2. I rebase/collapse this set of changes into a single PR, excluding the distlib and test fixes that are covered separately. Any suggestions on git incantations to do this would be gratefully accepted, otherwise, I'll probably just copy the various files and hack it using diff.

I'll leave it now till we get a new distlib release.

If anyone can think of anything I've forgotten, let me know.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Oct 27, 2013

Member
$ git checkout <your branch>
$ git rebase -i develop

When your text editor opens you can rearrange the lines, delete lines to delete commits, or change the "pick" line to one of:

# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell

So like

pick abcdf ....
squash ggasd ...

Will merge abdf and ggasd into a single commit, and reopen the editor allowing you to edit the combined commit message. You can squash as many commits as you like into one commit as well.

Member

dstufft commented Oct 27, 2013

$ git checkout <your branch>
$ git rebase -i develop

When your text editor opens you can rearrange the lines, delete lines to delete commits, or change the "pick" line to one of:

# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell

So like

pick abcdf ....
squash ggasd ...

Will merge abdf and ggasd into a single commit, and reopen the editor allowing you to edit the combined commit message. You can squash as many commits as you like into one commit as well.

@vsajip

This comment has been minimized.

Show comment
Hide comment
@vsajip

vsajip Oct 27, 2013

Contributor

I'll do a release of distlib in the next few days - are you reasonably sure there won't be any more distlib changes needed for its usage by pip?

Contributor

vsajip commented Oct 27, 2013

I'll do a release of distlib in the next few days - are you reasonably sure there won't be any more distlib changes needed for its usage by pip?

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 27, 2013

Member

@vsajip - not in respect of this change, at least.
@dstufft - thanks, that's excellent. I'll give that a go. Presumably I'll need to delete & recreate the github copy of the branch after history hacking like this?

Member

pfmoore commented Oct 27, 2013

@vsajip - not in respect of this change, at least.
@dstufft - thanks, that's excellent. I'll give that a go. Presumably I'll need to delete & recreate the github copy of the branch after history hacking like this?

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Oct 27, 2013

Member

git push -f origin script-generation

Be careful with git push -f, it's a destructive operation, it stands for force and it says "I don't care if this isn't a child of what you already have for the named reference, this is what I want it to be".

Member

dstufft commented Oct 27, 2013

git push -f origin script-generation

Be careful with git push -f, it's a destructive operation, it stands for force and it says "I don't care if this isn't a child of what you already have for the named reference, this is what I want it to be".

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 27, 2013

Member

OK, nice. I'm not too worried if I get the github branch wrong, as I was originally planning on deleting & recreating anyway :-)

Thanks for the git help. I feel like it's possible to do pretty much anything with git, it's just almost impossible to find out how :-)

Member

pfmoore commented Oct 27, 2013

OK, nice. I'm not too worried if I get the github branch wrong, as I was originally planning on deleting & recreating anyway :-)

Thanks for the git help. I feel like it's possible to do pretty much anything with git, it's just almost impossible to find out how :-)

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Oct 27, 2013

Member

No problem! I've learned the dark magic internals of git, so my brain is sufficiently broken that I understand it! Feel free to ask me anytime.

Mostly the thing you want to make sure is you don't actually force push your branch to master or something.

Member

dstufft commented Oct 27, 2013

No problem! I've learned the dark magic internals of git, so my brain is sufficiently broken that I understand it! Feel free to ask me anytime.

Mostly the thing you want to make sure is you don't actually force push your branch to master or something.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 29, 2013

Member

@dstufft That worked really well, thanks.

Member

pfmoore commented Oct 29, 2013

@dstufft That worked really well, thanks.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Oct 31, 2013

Member

Just wondering what the status of this is?

Member

dstufft commented Oct 31, 2013

Just wondering what the status of this is?

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 31, 2013

Member

Was ready to go pending @vsajip releasing a new version of distlib. Looks like something has since been commited that conflicts, so I'll have to rebase :-( I'm not going to do anything though till distlib 0.1.4 lands.

Member

pfmoore commented Oct 31, 2013

Was ready to go pending @vsajip releasing a new version of distlib. Looks like something has since been commited that conflicts, so I'll have to rebase :-( I'm not going to do anything though till distlib 0.1.4 lands.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 31, 2013

Member

OK, distlib 0.1.4 is vendored. Thanks @vsajip!

I will work on rebasing these changes and getting them merged tomorrow.

Member

pfmoore commented Oct 31, 2013

OK, distlib 0.1.4 is vendored. Thanks @vsajip!

I will work on rebasing these changes and getting them merged tomorrow.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Nov 1, 2013

Member

OK, this is ready to go. I'll let it sit for the rest of the day in case anyone has last minute issues they want to raise, then commit this evening (GMT).

Member

pfmoore commented Nov 1, 2013

OK, this is ready to go. I'll let it sit for the rest of the day in case anyone has last minute issues they want to raise, then commit this evening (GMT).

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Nov 1, 2013

Contributor

Looking at this now..

Contributor

qwcode commented Nov 1, 2013

Looking at this now..

Show outdated Hide outdated pip/wheel.py Outdated
if len(console) > 0:
generated.extend(maker.make_multiple(['%s = %s' % kv for kv in console.items()]))
if len(gui) > 0:
generated.extend(maker.make_multiple(['%s = %s' % kv for kv in gui.items()], {'gui': True}))

This comment has been minimized.

@qwcode

qwcode Nov 1, 2013

Contributor

maybe a comment above these 4 lines "Generate console and gui scripts"

@qwcode

qwcode Nov 1, 2013

Contributor

maybe a comment above these 4 lines "Generate console and gui scripts"

if cp.has_section('gui_scripts'):
gui = dict(cp.items('gui_scripts'))
return console, gui
def move_wheel_files(name, req, wheeldir, user=False, home=None, root=None):

This comment has been minimized.

@qwcode

qwcode Nov 1, 2013

Contributor

this function has become really large with 4 embedded functions. time for a class IMO.
it's not you're problem Paul, but it's become a problem for the project.

@qwcode

qwcode Nov 1, 2013

Contributor

this function has become really large with 4 embedded functions. time for a class IMO.
it's not you're problem Paul, but it's become a problem for the project.

This comment has been minimized.

@pfmoore

pfmoore Nov 1, 2013

Member

Agreed. I'd have refactored more but the embedded functions use various locals and it was going to be messy to do so. I'll try and do a refactoring soon while the way the code works is fresh in my mind - it would be nice if this function were more maintainable.

@pfmoore

pfmoore Nov 1, 2013

Member

Agreed. I'd have refactored more but the embedded functions use various locals and it was going to be messy to do so. I'll try and do a refactoring soon while the way the code works is fresh in my mind - it would be nice if this function were more maintainable.

maker = ScriptMaker(None, scheme['scripts'])
maker.variants = set(('', ))
# Special case pip and setuptools to generate versioned wrappers

This comment has been minimized.

@qwcode

qwcode Nov 1, 2013

Contributor

what's the story on this again? why not just honor what we have in our setup.py?

      entry_points=dict(console_scripts=['pip=pip:main', 'pip%s=pip:main' % sys.version[:1],
          'pip%s=pip:main' % sys.version[:3]]),
@qwcode

qwcode Nov 1, 2013

Contributor

what's the story on this again? why not just honor what we have in our setup.py?

      entry_points=dict(console_scripts=['pip=pip:main', 'pip%s=pip:main' % sys.version[:1],
          'pip%s=pip:main' % sys.version[:3]]),

This comment has been minimized.

@dstufft

dstufft Nov 1, 2013

Member

Because entry points are computed at wheel build time, so because of the line you pasted it would otherwise make what could be a universal wheel, Python version specific. With this change we override those values so that a Wheel made on Python 2.7 when isntalling in 3.4 does not install a pip2.7 binary that is actually installed with Python 3.4.

@dstufft

dstufft Nov 1, 2013

Member

Because entry points are computed at wheel build time, so because of the line you pasted it would otherwise make what could be a universal wheel, Python version specific. With this change we override those values so that a Wheel made on Python 2.7 when isntalling in 3.4 does not install a pip2.7 binary that is actually installed with Python 3.4.

This comment has been minimized.

@qwcode

qwcode Nov 1, 2013

Contributor

i.e. it seems like we'd either honor setup.py for all projects, or override for all projects. why pip and setuptools only?

and if it's just pip and setuptools, why not just update our setup.py

whatever the answer, can we add a comment about it.

@qwcode

qwcode Nov 1, 2013

Contributor

i.e. it seems like we'd either honor setup.py for all projects, or override for all projects. why pip and setuptools only?

and if it's just pip and setuptools, why not just update our setup.py

whatever the answer, can we add a comment about it.

This comment has been minimized.

@dstufft

dstufft Nov 1, 2013

Member

This is mimic'ing our setup.py at wheel build time, and it's a temporary measure until Metadata 2.0 has proper support for versionined entry points.

@dstufft

dstufft Nov 1, 2013

Member

This is mimic'ing our setup.py at wheel build time, and it's a temporary measure until Metadata 2.0 has proper support for versionined entry points.

This comment has been minimized.

@qwcode

qwcode Nov 1, 2013

Contributor

why do need to mimic? what's in setup.py, will be replicated in entry_points.txt, and we just follow that.

[console_scripts]
pip = pip:main
pip2.7 = pip:main
pip2 = pip:main
@qwcode

qwcode Nov 1, 2013

Contributor

why do need to mimic? what's in setup.py, will be replicated in entry_points.txt, and we just follow that.

[console_scripts]
pip = pip:main
pip2.7 = pip:main
pip2 = pip:main

This comment has been minimized.

@qwcode

qwcode Nov 1, 2013

Contributor

Wheel made on Python 2.7 when isntalling in 3.4 does not install a pip2.7 binary

oh, ok. for python-version agnostic wheels. let's comment on that.
but why is only true for pip and setuptools?

@qwcode

qwcode Nov 1, 2013

Contributor

Wheel made on Python 2.7 when isntalling in 3.4 does not install a pip2.7 binary

oh, ok. for python-version agnostic wheels. let's comment on that.
but why is only true for pip and setuptools?

This comment has been minimized.

@dstufft

dstufft Nov 1, 2013

Member

Because if we don't mimic it then all of the pip wheels are Python version specific, so we'll need a separate Wheel for 2.6, 2.7, 3.1, 3.2, 3.3, and 3.4. If we mimic it here then A single universal Wheel will work for all versions of Python.

@dstufft

dstufft Nov 1, 2013

Member

Because if we don't mimic it then all of the pip wheels are Python version specific, so we'll need a separate Wheel for 2.6, 2.7, 3.1, 3.2, 3.3, and 3.4. If we mimic it here then A single universal Wheel will work for all versions of Python.

This comment has been minimized.

@pfmoore

pfmoore Nov 1, 2013

Member

But that section you quote would generate pip2.7.exe even when the wheel is installed using Python 3.3. The only way to get the versioned entry points matching the interpreter we're installing with, is to generate the names at install time. Or to have a separate wheel for each version, which is what we're trying to avoid.

Long term, the proper solution will be for the metadata to be able to say that we want versioned entry points. But that metadata doesn't exist yet, and rather than make up our own temporary solution, it was easier to just special-case pip and setuptools for now.

Agreed that this is confusing, though. I will add a comment (hopefully not an essay!)

@pfmoore

pfmoore Nov 1, 2013

Member

But that section you quote would generate pip2.7.exe even when the wheel is installed using Python 3.3. The only way to get the versioned entry points matching the interpreter we're installing with, is to generate the names at install time. Or to have a separate wheel for each version, which is what we're trying to avoid.

Long term, the proper solution will be for the metadata to be able to say that we want versioned entry points. But that metadata doesn't exist yet, and rather than make up our own temporary solution, it was easier to just special-case pip and setuptools for now.

Agreed that this is confusing, though. I will add a comment (hopefully not an essay!)

This comment has been minimized.

@qwcode

qwcode Nov 1, 2013

Contributor

ok, I think I got this now. we have no convention to do this generally for all projects.
but please add a comment on why we're doing this. thanks.

@qwcode

qwcode Nov 1, 2013

Contributor

ok, I think I got this now. we have no convention to do this generally for all projects.
but please add a comment on why we're doing this. thanks.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Nov 1, 2013

Member

Thanks @qwcode for the thorough review. I will update the patch accordingly.

Member

pfmoore commented Nov 1, 2013

Thanks @qwcode for the thorough review. I will update the patch accordingly.

@qwcode

This comment has been minimized.

Show comment
Hide comment
@qwcode

qwcode Nov 1, 2013

Contributor

@pfmoore , other than the wording issues I brought up, LGTM.

Contributor

qwcode commented Nov 1, 2013

@pfmoore , other than the wording issues I brought up, LGTM.

pfmoore added a commit that referenced this pull request Nov 1, 2013

@pfmoore pfmoore merged commit 780e9d4 into pypa:develop Nov 1, 2013

1 check passed

default The Travis CI build passed
Details

@pfmoore pfmoore deleted the pfmoore:script-generation branch Nov 2, 2013

mitya57 added a commit to retext-project/retext that referenced this pull request Feb 6, 2018

Recommend using pip3 instead of pip
Versioned commands are available since pypa/pip#1053, or pypa/pip#1251
if pip is installed from a wheel.

Fixes #353.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment