On Thu, Jan 30, 2014 at 11:48 AM, Donald Stufft <[email protected]> wrote: > > On Jan 30, 2014, at 11:44 AM, Evgeny Sazhin <[email protected]> wrote: > >> On Thu, Jan 30, 2014 at 9:38 AM, Donald Stufft <[email protected]> wrote: >>> >>> On Jan 29, 2014, at 11:29 PM, Evgeny Sazhin <[email protected]> wrote: >>> >>>> >>>> On Jan 29, 2014, at 11:17 PM, Donald Stufft <[email protected]> wrote: >>>> >>>>> >>>>> On Jan 29, 2014, at 11:16 PM, Evgeny Sazhin <[email protected]> wrote: >>>>> >>>>>> >>>>>> On Jan 29, 2014, at 10:49 PM, Donald Stufft <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> On Jan 29, 2014, at 10:47 PM, Evgeny Sazhin <[email protected]> wrote: >>>>>>> >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> I didn't say anything about self-unpacking executable. Egg already >>>>>>>> knows to do what is needed, so i was correct in expecting the wheel to >>>>>>>> do the same. Plus the notion of packages for transmitting and >>>>>>>> installing should not exclude the running and importing. Otherwise it >>>>>>>> is useless, at least for my purposes. As discussed before - jar does >>>>>>>> that just fine and it is a package format. >>>>>>>> >>>>>>>> Funny thing - wheel allows to do the same! Why would i want to use >>>>>>>> anything else then??? >>>>>>> >>>>>>> Because Python is not Java and Wheels are not Jars. You'll find very >>>>>>> few packages actually support being run from a zipped file and the >>>>>>> failure modes are not always obvious. >>>>>> >>>>>> I understand that not a lot of currently existing project are using this >>>>>> capability - but I'm 100% positive that if the running from wheel would >>>>>> be properly supported on error handling level and officially declared at >>>>>> least for the pure python - most of the people would be happy to have >>>>>> that! If we think about that, why would i want to use anything else >>>>>> other than wheel and pip if this pair gives the possibility to >>>>> >>>>> Pip does not install zipped wheels, and while it's not entirely up to me >>>>> I would be opposed to it getting the ability to do so. >>>> >>>> I might be poorly wording things - but i never said I want pip to install >>>> the zipped wheel. It seems that you're missing the point a bit. >>>> I'm totally fine with the way pip handles things. >>>> >>>> again briefly My idea is to use the following: >>>> >>>> central location - flat folder with wheels, accessible to read for >>>> everybody in network. >>>> >>>> for development : pip and virtual env. project has the virtual env >>>> created, dependencies are deployed and available for development and >>>> debugging in a standard manner. When done the project is packaged into >>>> wheel that is getting deployed to central location. >>>> >>>> To *run* the program: i would create a script that bases on the pip >>>> ability to resolve dependencies and basing on the requirements.txt from >>>> inside my wheel it would generate PYTHONPATH to prepend the starting call >>>> like that: >>>> PYTHONPATH=1.whl:2.whl; python 3.whl >>>> >>>> where 3.whl is program with __main__.py and 1.whl and 2.whl are >>>> dependencies needed. This works as of now! >>> >>> Just use pip and virtualenv in production. It's bad form to install things >>> differently in development than in production. It *will* lead to production >>> only bugs and in the case of zip imports it'll lead to hard to diagnose >>> errors and bugs that you'll never be able to reproduce in development. >> >> >> I'm happy to concede the run from zip thing if somebody could explain >> how should i use pip and virtualenv in production? >> Currently it seems to be very clean and clear. I can have one folder >> where i can dump multiple versions of the same project in wheel format >> and having requirements.txt in each of them i can construct PYTHONPATH >> and run things. Simple! >> >> How am i supposed to manage that using pip and virtual envs in production? > > The same way you'd use them in development? Hell I believe you can even do: > > $ virtualenv my_virtualenv > $ my_virtualenv/bin/pip install path/to/wheelhouse/* > > The point is it's just installed libraries, asking this question doesn't > really make much > sense, it's like asking how do you use apt-get or yum in production. > >>
Could you please reread this https://mail.python.org/pipermail/distutils-sig/2014-January/023636.html I'm explaining there what is the task at hand and why I'm favoring the jar-like workflow for deployment. Thanks, Eugnee _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
