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

[Evgeny Sazhin]

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.
>
> Cheers,
> Paul

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;)

Thanks,
Eugene