experimental support for installing wheel archives

[qwcode]

This is just the install support w/o wheel building/caching.
The "pip build/bdist_wheel" effort will take more time since it involves some refactor and maybe some debate.

[qwcode]

@dholth @pfmoore, @pnasrat @rubik : ok, here's just the install support. let me know if I mis-carved anything.

@pfmoore : notice/confirm the fix I made related to your new "binary" function for py3. you can see the previous failure here: https://travis-ci.org/#!/pypa/pip/jobs/2633020

also, @dholth, can you confirm my understanding of this in simple.dist metadata:

Requires-Dist: beaglevote; extra == 'voting'

I'm guessing that's there to test the extra syntax that only markerlib understands now? You can't install simple.dist w/o markerlib, because it complains about the non-existing beaglevote. So, if that's true, for now, I'm saying pip requires markerlib in the usage? or maybe only for extra syntax?

[dholth]

The next version of distribute will include markerlib. Until then, all markers evaluate to true (oops) And pip will try to install all the extras. Distribute 0.6.28 is required.

For py 2.5 markerlib doesn't work (no compile(ast)) so we just make non-empty markers false, empty ones or no markers are true. They work correctly in 2.6 and up.

On Oct 2, 2012, at 2:42 AM, Marcus Smith notifications@github.com wrote:

@dholth @pfmoore, @pnasrat @rubik : ok, here's just the install support. let me know if I mis-carved anything.

@pfmoore : notice/confirm the fix I made related to your new "binary" function for py3

also, @dholth, can you confirm my understanding of this in simple.dist metadata:

Requires-Dist: beaglevote; extra == 'voting'
I'm guessing that's there to test the extra syntax that only markerlib understands now? You can't install simple.dist w/o markerlib, because it complains about the non-existing beaglevote. So, if that's true, for now, I'm saying pip requires markerlib in the usage? or maybe only for extra syntax?

—
Reply to this email directly or view it on GitHub.

[dholth]

Use exename instead of binary()

On Oct 2, 2012, at 2:42 AM, Marcus Smith notifications@github.com wrote:

@dholth @pfmoore, @pnasrat @rubik : ok, here's just the install support. let me know if I mis-carved anything.

@pfmoore : notice/confirm the fix I made related to your new "binary" function for py3

also, @dholth, can you confirm my understanding of this in simple.dist metadata:

Requires-Dist: beaglevote; extra == 'voting'
I'm guessing that's there to test the extra syntax that only markerlib understands now? You can't install simple.dist w/o markerlib, because it complains about the non-existing beaglevote. So, if that's true, for now, I'm saying pip requires markerlib in the usage? or maybe only for extra syntax?

—
Reply to this email directly or view it on GitHub.

[qwcode]

The next version of distribute will include markerlib.
Until then, all markers evaluate to true (oops) And pip will try to install all the extras. Distribute 0.6.28 is required.

@dholth , to be clear...

1. the beaglevote extra requirement in simple.dist is intentional and should be left in? yes?
2. so for the short term though, we should say markerlib is required... certain version?

[qwcode]

@dholth , @pfmoore. using exename now in latest commit. travis running...

[dholth]

Yes, and the newest markerlib

Marcus Smith notifications@github.com wrote:

The next version of distribute will include markerlib.
Until then, all markers evaluate to true (oops) And pip will try to install all the extras. Distribute 0.6.28 is required.

@dholth , to be clear...

1. the beaglevote extra requirement in simple.dist is intentional and should be left in? yes?
2. so for the short term though, we should say markerlib is required... certain version?

---

Reply to this email directly or view it on GitHub:
#694 (comment)

[qwcode]

@dholth @pnasrat @pfmoore @rubik @brosner @jezdez

I'm ready to merge... anyone have concerns?

here's my list of reasons for why this is ok and good:

1. wheels are only found if the user specifically uses the --use-wheel flag (or ofcourse if they install a wheel directly)
2. the code is isolated enough for easy removal later, if the "experiment" fails
3. pip users need binary install support
4. wheel has momentum.
5. there's multiple people contributing to this effort and reviewing.
6. this isn't final; we'll keep improving this (namely in adding tag support and wheel building)
7. we'll get more feedback and have better coordination this way vs it being a long running feature branch in dholth's fork.

[qwcode]

@dholth @rubik @pfmoore :
I posted my thoughts for the new subcommand to handle wheel building. comments appreciated.
https://gist.github.com/3828683
If any of you think you might work on this, let me know. otherwise, I'd probably end up doing it in a week or so.
the idea being to reuse some of the work by @rubik, but just in subcommand form

[qwcode]

@dholth @rubik @pfmoore :
also, since the more general topic of "caching" came up, I'm also thinking thru a new "--package-cache" option to "pip install"
https://gist.github.com/3828762
comments appreciated on that too.

[brosner]

I don't see the commit 941390f in the develop branch of pip. Did something happen?

[qwcode]

Jannis and I talked on IRC. he thought it was premature. not enough input. I reverted and will reopen this pull and post something on the mailing list to get more input and conversation going.

[rubik]

What? But if this does not get merged how can more people try it?

[jezdez]

@rubik check out #699 and install @qwcode's wheel_install branch. E.g. run in a venv: pip install https://github.com/qwcode/pip/zipball/wheel_install and try it yourself.