allow creating wheels for editable packages

[sbidoul]

Fixes #3291

This lifts the restriction of not generating wheels for editable packages.

As explained in #3291, there are legitimate scenarios for this, such as building wheels from frozen requirements.

[xavfernandez]

There might be legitimate reason but I don't think it should be the default behavior: if the user did not update the editable package's version in setup.py, it will end up with a wheel named pkg-1.5.2-py2.py3-none-any.whl but different than the correctly generated pkg-1.5.2-py2.py3-none-any.whl.

This hazardous behavior could be enable via an --allow-editable (or some nicer name) option however.

cc @qwcode since you commented on #1775 :)

[sbidoul]

Ah, now I understand the reason. Thanks for the explanation, @xavfernandez.

I'll close this one and see if I can come up with a better solution.

[sbidoul]

@xavfernandez regarding your #3379 (comment) above, it looks like one can do pip wheel git+https://something... and the user can also have forgotten to update the version in that setup.py.

So I'm back to not understanding the restriction again.

[xavfernandez]

And you can also do pip wheel ./some_local_directory.
So indeed you already have ways to shoot yourself in the foot and this limitation on editable does not make that much sense.
We could maybe imagine printing out warnings on these border cases but I'm not sure it would be useful.

[xavfernandez]

On the other hand, I don't see the use case for wanting a wheel of an editable...
From #3291, it looks like this PR is a workaround for issue #2994.

[sbidoul]

@xavfernandez thanks for pointing me #2994.

That's not the core of my issue though. Really, when I pip freeze my project (an application, not a library), I get lines with -e. So I really expect to be able to pip wheel -r frozen-requirements.txt without fiddling with the output of pip freeze.

If remove the -e from my frozen requirements, it works, but it does a full git clone of my git dependencies in temporary directories. And that's really an issue because I have one dep (Odoo, to name it) where git clone means dowloading 1GB. If I can do a pip wheel from the editable requirement, it uses the clone I already have in src for development.

So all in all, being able to pip freeze editable requirements is really helpful for the development workflow of applications.

I updated the PR with a more correct solution (the failure is a transient travis error).

[sbidoul]

@xavfernandez is my use case valid? If positive I can work on a test.

[piotr-dobrogost]

Could some maintainer take a look at this and hopefully give a green light?

[dstufft]

Accidentally closed this, reopening. Sorry!

[BrownTruck]

Hello!

As part of an effort to ease the contribution process and adopt a more standard workflow pip has switched to doing development on the master branch. However, this Pull Request was made against the develop branch so it will need to be resubmitted against master.

If you do nothing, this Pull Request will be automatically migrated by @BrownTruck for you.

If you would like to retain control over this pull request then you should resubmit it against the master branch, closing and referencing the original Pull Request.

If you choose to migrate this Pull Request yourself, here is an example message that you can copy and paste:

Fixes #3291 

This lifts the restriction of not generating wheels for editable packages.

As explained in #3291, there are legitimate scenarios for this, such as building wheels from frozen requirements.

---

*This was migrated from pypa/pip#3379 to reparent it to the ``master`` branch. Please see original pull request for any previous discussion.*

If this pull request is no longer needed, please feel free to close it.

[sbidoul]

reparented to the master branch in #3695