[Distutils] PEP 427

Evgeny Sazhin eugene at sazhin.us
Thu Jan 30 00:34:43 CET 2014


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!!;)

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


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?

More information about the Distutils-SIG mailing list