A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2011-June/111907.html below:

[Python-Dev] In-Python virtualisation and packaging

[Python-Dev] In-Python virtualisation and packagingVinay Sajip vinay_sajip at yahoo.co.uk
Mon Jun 13 14:50:01 CEST 2011
Nick Coghlan <ncoghlan <at> gmail.com> writes:

> Given that it is desirable for tools like virtualenv to support *old*
> versions of Python on *new* versions of operating systems, it seems to
> me that there is an inherent element of their feature set that makes
> including the whole tool questionable.

You're right in terms of the current Python ecosystem and 3.x adoption, because
of course this approach requires support from Python itself in terms of its
site.py code. However, virtual environments have a utility beyond supporting
older Pythons on newer OSes, since another common use case is having different
library environments sandboxed from each other on different projects, even if
all those projects are using Python 3.3+. The virtualenv module does an
intricate bootstrapping dance which needs to accommodate each successive Python
version, so there's maintenance overhead that way, too. Carl Meyer, being a pip
and virtualenv maintainer, will probably have useful views on this.

> OTOH, it may make sense to have a baseline tool provided innately, but
> provide the appropriate third party hooks to allow alternative tools
> to evolve independently of the stdlib.

Yes - I'm thinking that what I've proposed is the baseline tool, and the
question is about what the virtualisation API needs to look like to allow
third-party tools to progress independently of the stdlib but in an
interoperable way (a bit like packaging, I suppose).

> How well does the regression test suite cope when run inside such a
> virtualised environment?

https://gist.github.com/1022705

325 tests OK.
5 tests failed:
    test_email test_importlib test_lib2to3 test_packaging
    test_sysconfig

test_importlib might be broken because I accidentally committed some changes to
marshal.c while working on #12291.

test_packaging fails because of #12313.
test_email fails for a similar reason - Makefile.pre.in is missing test_email in
LIBSUBDIRS.

test_sysconfig is probably failing because of changes I made, and I'm not sure
of test_lib2to3. I will investigate!

Regards,

Vinay Sajip

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4