"pip wheel"

gistfile1.txt

Usage: pip wheel [OPTIONS] PACKAGE_NAMES...

Creates wheel archives from your requirements and place into ./wheels
(requires distribute>0.6.28 and wheel)

 -w --wheel-dir <DIR>  //alternative dir to place wheels into
 --force-rebuild               //rewrite existing wheels
 --unpack-only  <DIR>  //unpack to dir, for manual building with "setup.py bdist_wheel"
 -r, --requirement <FILENAME>
 -f, --find-links <URL>      
 -i, --index-url <URL>       
 --extra-index-url <URL>   
 --no-index              
 -M, --use-mirrors       
 --mirrors <URL>         
 --download-cache <DIR> 
 --no-deps     


why not other names?
  - "pip bdist --format=[wheel...]":  if wheel succeeds, would we seriously want to support any of the older forms?
  - "pip build ..." 
     - if the intention here is to just label wheel building as "build", IMHO that will create confusion.
     - if the intention is to do something much more elaborate, e.g also trying to break up the "setup.py install" step, that's too much IMHO

design:
   - you can't just inherit from commands.install, or you take on all install options.  that's too confusing
   - either inherit directly from pip.basecommand.command (and construct a RequirmentSet), 
     or possibly do some refactor and create a new ReqSet command base class, if it makes sense 
   - feel free to modify and *add* methods to InstallRequirement/RequirementSet.  
      (better to not make these enormously long methods any longer and complicated)

P.S. if the general "--package-cache" idea succeeds( https://gist.github.com/3828762), 
    then I could see coming back and offering a "--build-wheel" option to install that builds/writes 
    wheels to your package-cache if you're using one.


  

Very nice proposal, I have one question though: why not using no_install? Is the new command supposed to replicate all the logic behind it?
I agree on the name, bdist is too general, and I don't think we need other built distributions, since wheel is way better than the other ones (in my opinion).

This is a nice design.

"pip install --no-install" is an enigma that carl and I agreed was rather odd. Does anybody use it? IMO, either it get's dropped, or maybe rename it to "--unpack", or move it over to something like "pip unpack".
(but not as part of this effort)

As it is, options.no_install is not used in req.py. it only does conditional work in pip.commands.install.
So this new command shouldn't have any interaction with any notion of no_install.

I like the design. It looks clean and to the point. I agree with the idea of not over-generalising with things like "pip bdist" or "pip build" at this point.

One additional thought - the existing "pip install --wheel-cache" approach fails to build a wheel for something you already have installed (say, wheel or pip itself). I assume that the new pip wheel command will ignore whether or not the packages are already installed?

Another data point. When a package needs custom build_ext options (usually -L or -I for external libraries) the current incantation is

pip install --build t --no-install PKG
cd t/PKG
python setup.py build_ext -I xxx -L yyy
cd ../..
pip install --build t --no-install --wheel-cache Wheels PKG

The new pip wheel command needs to respect --build for this to work. Assuming you don't want to invent a more complex automatic method of passing arguments to setup.py. (Which would be nice, but probably a lot more work than you want to bother with...)

You can use pip install --ignore-installed to build a more complete cache. There needs to be a shortcut for "ignore everything except distribute" given the trouble pip has upgrading its own dependency, or pip could just ignore distribute all the time since upgrading distribute with pip is generally a bad idea.

If you have a tricky build, wouldn't you just run python setup.py bdist_wheel for the tricky dist? pip could include the "run any setup.py under setuptools" as a script.

assume that the new pip wheel command will ignore whether or not the packages are already installed?

that's my intention

When a package needs custom build_ext options (usually -L or -I for external libraries) the current incantation is

I guess at least support an --unpack-only option (so you can manually do certain ones)?

Assuming you don't want to invent a more complex automatic method of passing arguments to setup.py

wasn't planning on it, but related to this, there is a pull to add --install-option support line by line in requirements, but it's stagnating. pypa/pip#515