[Distutils] PEP 427

[Noah Kantrowitz]

On Jan 29, 2014, at 9:50 AM, 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?

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.

--Noah

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