[Distutils] wheels on sys.path clarification (reboot)

[Paul Moore]

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.

Cheers,
Paul