On Thu, Jan 30, 2014 at 9:38 AM, Donald Stufft <donald@stufft.io> wrote:
On Jan 29, 2014, at 11:29 PM, Evgeny Sazhin <eugene@sazhin.us> wrote:
On Jan 29, 2014, at 11:17 PM, Donald Stufft <donald@stufft.io> wrote:
On Jan 29, 2014, at 11:16 PM, Evgeny Sazhin <eugene@sazhin.us> wrote:
On Jan 29, 2014, at 10:49 PM, Donald Stufft <donald@stufft.io> wrote:
On Jan 29, 2014, at 10:47 PM, Evgeny Sazhin <eugene@sazhin.us> wrote:
> > Wheel is a package format. Packages are for transmitting and installing bits. If you want to make some kind of self-unpacking executable please do it with something built for it. makeself is an excellent choice for these. >
I didn't say anything about self-unpacking executable. Egg already knows to do what is needed, so i was correct in expecting the wheel to do the same. Plus the notion of packages for transmitting and installing should not exclude the running and importing. Otherwise it is useless, at least for my purposes. As discussed before - jar does that just fine and it is a package format.
Funny thing - wheel allows to do the same! Why would i want to use anything else then???
Because Python is not Java and Wheels are not Jars. You'll find very few packages actually support being run from a zipped file and the failure modes are not always obvious.
I understand that not a lot of currently existing project are using this capability - but I'm 100% positive that if the running from wheel would be properly supported on error handling level and officially declared at least for the pure python - most of the people would be happy to have that! If we think about that, why would i want to use anything else other than wheel and pip if this pair gives the possibility to
Pip does not install zipped wheels, and while it's not entirely up to me I would be opposed to it getting the ability to do so.
I might be poorly wording things - but i never said I want pip to install the zipped wheel. It seems that you're missing the point a bit. I'm totally fine with the way pip handles things.
again briefly My idea is to use the following:
central location - flat folder with wheels, accessible to read for everybody in network.
for development : pip and virtual env. project has the virtual env created, dependencies are deployed and available for development and debugging in a standard manner. When done the project is packaged into wheel that is getting deployed to central location.
To *run* the program: i would create a script that bases on the pip ability to resolve dependencies and basing on the requirements.txt from inside my wheel it would generate PYTHONPATH to prepend the starting call like that: PYTHONPATH=1.whl:2.whl; python 3.whl
where 3.whl is program with __main__.py and 1.whl and 2.whl are dependencies needed. This works as of now!
Just use pip and virtualenv in production. It's bad form to install things differently in development than in production. It *will* lead to production only bugs and in the case of zip imports it'll lead to hard to diagnose errors and bugs that you'll never be able to reproduce in development.
I'm happy to concede the run from zip thing if somebody could explain how should i use pip and virtualenv in production? Currently it seems to be very clean and clear. I can have one folder where i can dump multiple versions of the same project in wheel format and having requirements.txt in each of them i can construct PYTHONPATH and run things. Simple! How am i supposed to manage that using pip and virtual envs in production? Thanks, Eugene