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? Thanks, Eugene _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
