On Jan 29, 2014, at 6:34 PM, Evgeny Sazhin <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>> >>> >>> >>> On Wed, Jan 29, 2014 at 9:11 AM, Vinay Sajip <[email protected]> >>> 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 - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
