[Distutils] wheels on sys.path clarification (reboot)
dholth at gmail.com
Thu Jan 30 19:24:09 CET 2014
One thing that might be useful would be to develop the "unpacked
wheel" which is currently undefined but would be deliberately
identical to a site-packages with just one wheel extracted into it.
You wouldn't have to argue or worry about the zip issue.
I like the way npm puts everything into a directory
~/.npm/packagename/0.4.2/ ... for example, gem is similar. If you
really wanted to go to town you could figure out how to do virtualenvs
with hardlinks or reflinks instead of copies (conda can).
But as has been repeated you won't find robust support for this in the
On Thu, Jan 30, 2014 at 1:19 PM, Evgeny Sazhin <eugene at sazhin.us> wrote:
> On Thu, Jan 30, 2014 at 12:56 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>> On 30 January 2014 16:33, Evgeny Sazhin <eugene at sazhin.us> wrote:
>>>> I don't have good
>>>> references or pointers to good Python development or deployment
>>>> practices, but you may want to ask around on python-list.
>>> And that is my biggest concern (deployment). I believe these questions
>>> should be answered by wheels or python packaging specification.
>>> Not by third party tooling. The language should be able to work with
>>> artifacts/packages produced for the language by the language. Third
>>> party tools may allow for automation, continuous integration
>>> complicated deployments and whatnot. But the base must be there.
>> There's 2 distinct concepts in the Python world, that you should be
>> aware of. Application deployment and library deployment.
>> Library deployment is simple. Build your library and upload it as a
>> source distribution (sdist) and one or more wheels to PyPI (if it's a
>> public project) or a local index (if it's a private project). People
>> or other projects will use the library however they deem appropriate,
>> typically by doing "pip install projectname" to make the code
>> accessible. That unpacks the wheel into a local site-packages, but you
>> have no need to care about that.
>> Application deployment is not as straightforward - there are a number
>> of common approaches and at least as many opinions on what you should
>> do. You may bundle Python and your code and its dependencies together
>> into a standalone executable, using a tool like cx_Freeze. or you may
>> use something like buildout (I can't give details as I've never used
>> this). You can also, in some cases, package your application main code
>> in the same way as a library, and use "entry points" to define the
>> executables - that will then be installed by the end user into an
>> existing Python installation.
>> As an application developer, you typically wouldn't care about how the
>> end user deployed your code for execution, unless you were bundling
>> via something like cx_Freeze. You might choose to bundle your
>> application code *without* a Python interpreter. That's basically what
>> executable zipfiles are about, and it's probably the closest
>> equivalent to Java jars. But that's not a particularly well-travelled
>> route in the Python community (yet) - there are projects like pyzzer
>> that automate certain aspects of that process, but in general, you
>> have to "roll your own" solution here.
>> Hopefully that makes some sense - I'm getting pretty burned out with
>> the various threads going on at the moment, so I'm probably glossing
>> over a lot.
> Thanks Paul - you are very helpful! this is good distinction and i
> think i'm coming to it as well. I just suggested one approach that
> might be feasible in my case in another thread;)
> Everybody - I'm really grateful for the time you are willing to spend
> in helping me to understand the state of the things. I hope this
> discussion might be helpful for both sides and may be people like me
> can be referenced to it in future;)
> PS That doesn't mean i will stop arguing with you;)
> Distutils-SIG maillist - Distutils-SIG at python.org
More information about the Distutils-SIG