[Distutils] PEP 427

[Daniel Holth]

On Thu, Jan 30, 2014 at 12:23 PM, Evgeny Sazhin <eugene at sazhin.us> wrote:
> On Thu, Jan 30, 2014 at 11:48 AM, Donald Stufft <donald at stufft.io> wrote:
>>
>> On Jan 30, 2014, at 11:44 AM, Evgeny Sazhin <eugene at sazhin.us> wrote:
>>
>>> On Thu, Jan 30, 2014 at 9:38 AM, Donald Stufft <donald at stufft.io> wrote:
>>>>
>>>> On Jan 29, 2014, at 11:29 PM, Evgeny Sazhin <eugene at sazhin.us> wrote:
>>>>
>>>>>
>>>>> On Jan 29, 2014, at 11:17 PM, Donald Stufft <donald at stufft.io> wrote:
>>>>>
>>>>>>
>>>>>> On Jan 29, 2014, at 11:16 PM, Evgeny Sazhin <eugene at sazhin.us> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Jan 29, 2014, at 10:49 PM, Donald Stufft <donald at stufft.io> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 29, 2014, at 10:47 PM, Evgeny Sazhin <eugene at 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?
>>
>> The same way you'd use them in development? Hell I believe you can even do:
>>
>>      $ virtualenv my_virtualenv
>>      $ my_virtualenv/bin/pip install path/to/wheelhouse/*
>>
>> The point is it's just installed libraries, asking this question doesn't really make much
>> sense, it's like asking how do you use apt-get or yum in production.
>>
>>>
>
> Could you please reread this
> https://mail.python.org/pipermail/distutils-sig/2014-January/023636.html
> I'm explaining there what is the task at hand and why I'm favoring the
> jar-like workflow for deployment.

It's clear that you favor the jar-like workflow. You will have
discover for yourself why it works or does not work for you. There is
more mature existing jar-like support for eggs (which will continue to
work for some time, but not be improved).

We do actually need a better way to turn libraries on and off
individually, for example, if I install the wrong set of Python
libraries on Ubuntu the plugin system for somesuch package crashes;
having everything installed importable all the time is a problem. Even
if you don't consider the unrelated packages that have chosen the same
module name.