[Distutils] PEP 427

[Evgeny Sazhin]

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

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?