[Distutils] PEP 427

[Donald Stufft]

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.

Even though the spec apparently allows it, using Wheels like this is an anti pattern.

> 
> 
> 
> 
>> 
>>> 1. use minimum of “standard” tools, 
>>> 
>>> 2. *manage dependencies* in a unified and standardized way 
>>> 
>>> 3. use only *one format* and *one artifact* per project for everything related to the code development, shipment, deployment and execution. 
>>> 
>>> What would be a motivation to learn yet another tool like buildout or anything, pollute infrastructure with more libraries, manage several different ways of working with the code, overcomplicate the production area by requiring stuff to be unzipped and whatnot? 
>>> 
>>> I hope nobody would want to strip any of those nice features from the wheel, but improve the running from it!;)
>> 
>> I don’t understand what any of the rest of this have to do with wether you add zipped Wheels to your sys.path or not.
> 
> see above 
> 
> 
>> 
>>> 
>>> Thanks,
>>> Eugene 
>>> 
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> Eugene
>>>>> _______________________________________________
>>>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>> 
>>>> 
>>>> -----------------
>>>> Donald Stufft
>>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>> 
>> 
>> -----------------
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140130/184de1cf/attachment.sig>