[Distutils] PEP 427

[Donald Stufft]

On Jan 29, 2014, at 6:34 PM, Evgeny Sazhin <eugene at sazhin.us> wrote:

> Guys,
> 
> I'm still unable to see my emails reaching the list for unknown reason...
> Any ideas what can be the problem?
> 
> FWIW I have tested it by adding the same __main__.py i used for the
> egg variant of the distribution
> to the wheel root and specifying
> $ PYTHONPATH=projectA.whl; python executable_projectB.whl
> 
> I was able to run the program!
> So it seems like the stuff does behave like a jar for pure python modules!
> 
> Don't know who to thank for that - because nobody seems to have
> claimed this functionality;)
> Well Nick said it supposed to be that way, So please don't break it!!;)

Wether this was “supposed” to be there is a matter that’s up for debate.

If you’re just using these for runtime you don’t need the Wheel format
at all. Just regular old pyzips will do just fine. 

http://docs.python.org/2/library/zipfile#pyzipfile-objects

> 
> It also means that I have the full picture in place without the
> necessity to use the buildout or anything else other then the pip and
> wheel from a flat folder structure! I'd appreciate if you could let me
> know about any problems you could foresee (we are talking pure python
> only)
> 
> Thanks!
> Eugene
> 
> 
> On Wed, Jan 29, 2014 at 5:36 PM, Evgeny Sazhin <eugene at sazhin.us> wrote:
>> I'm sorry for possible dup, but for whatever reason i don't see this
>> email reaching the list, so i'm resending.
>> 
>> 
>> On Wed, Jan 29, 2014 at 12:50 PM, Evgeny Sazhin <eugene at sazhin.us> wrote:
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Jan 29, 2014 at 9:11 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>>>> 
>>>>> Does it mean that it actually makes sense to look into that
>>>>> direction and make wheel usage closer to jar?
>>>> 
>>>> There is a parallel discussion going on, with the title "Using Wheel with zipimport",
>>>> which is relevant to this question, and other questions you raised (e.g. about
>>>> supporting C extensions/pure-Python modules.
>> 
>> 
>> 
>> I read all of it and got a bit lost in between the distil API and PEP
>> process discussion;)
>> 
>>> 
>>> 
>>>> 
>>>>> I have no knowledge about c extensions scope, but i feel
>>>>> like it might be of less importance then pure python
>>>>> packaging issues? Am I wrong?
>>>> 
>>>> A lot of Python users depend on C extensions - and while it is a subset of all Python
>>>> users, it is a large (and important) subset. Example: any usage of Python in
>>>> numerical analysis or scientific applications involves use of C extensions.
>>>> 
>>>> Regards,
>>>> 
>>>> Vinay Sajip
>>> 
>>> 
>>> 
>> 
>> I can see that it might be quite beneficial to have virtualenv and pip
>> installing wheels locally for development needs, so here is what i was
>> able to come up with so far:
>> 
>> I have one folder on NFS where all python developed stuff should be
>> *deployed* - pyhtonlib. It is impossible to use pip or virtualenv
>> there - so i'm bound to artifacts. The only way something can appear
>> there is by using the "release" program that knows how to put
>> artifacts in specified locations. Currently most of the stuff there is
>> the .py modules and few eggs (some are executable). But this stuff is
>> not allowing for sane dependency management, neither code reuse. I
>> actually don't like the idea of specifying dependencies in the code
>> via sys.path. I think the resolved sys.path based on requirements.txt
>> is much better solution.
>> 
>> So i'm looking for a solution that would allow to use the same
>> artifact for everything (like jar) so it can guarantee that the same
>> subset of code that was tested, goes to production and used in dev.
>> Currently I'm leaning towards using pip's capability to work with flat
>> folders via --find-links, so i can deploy wheels to the pythonlib and
>> then reuse them in the development environment.
>> 
>> But in this setup how do i make my program executable from pythonlib
>> location? I think I should I create some smart runner script that
>> would be able to use the pip's dependency resolution, create the
>> necessary sys.path basing on the wheel requirements.txt and then my
>> program wheel should have an entry point like __main__.py
>> 
>> As Nick pointed out the wheel is a superset of the egg - so I assume
>> wheels can be executable, correct? How do i achieve that?
> _______________________________________________
> 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

-------------- 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/20140129/b6cdc892/attachment.sig>