[Neuroimaging] Technical details managing Python versions and packages.

Matthew Brett matthew.brett at gmail.com
Mon Aug 3 17:52:33 CEST 2015

On Mon, Aug 3, 2015 at 4:49 PM, Yaroslav Halchenko <lists at onerussian.com> wrote:
> On Mon, 03 Aug 2015, Matthew Brett wrote:
>> > And only then, when I hit the situation that some package is not yet
>> > available from (Neuro)Debian, I usually create a virtualenv which
>> > complements system-wide collection (virtualenv --system-site-packages)
>> > and use its pip to install additional packages ideally by specifying
>> > them within requirements.txt (pip install -r requirements.txt) so I
>> > could later reproduce the same virtualenv.
>> As a matter of interest - how do you set up fresh environments to test in?
> it depends what I am testing. If I am testing Debian package of a
> module, tests are ran as part of the build process, and that one happens
> in a clean environment which is created usually as a chroot'ed
> environment with only build-depends installed (as specified in
> debian/control).  No virtualenv involved.
> I also have a set of chroots available locally so I could quickly switch
> to any given release of debian/ubuntu using schroot.
> then for 'semi-clean/mixed' environments I just use virtualenv (as
> described, i.e. with some packages coming from the system installation
> again), and now started to use tox more, which again preinstalls
> me those virtualenv's
>> One of the big advantages of virtualenv for this is you can test a
>> fresh install with no packages other than the stock pip / setuptools.
> yes -- for fresh packages, use virtualenv/tox.
> again as overlay on top of system wide installed ones.
> Why mixing up with system-wide -- because I want to test as when
> eventually this package would  get provided on a debian system, so with
> those other packages as available from the repository, not what at this
> given day available from pypi.
>> You can also easily junk a set of installs with:
>> rmvirtualenv my-env
>> How do you do that?
> not sure on specifics of this question -- "rm -rf my-env"? ;)  My
> virtualenvs aren't usually long-lived.

Sorry - I only meant that - if I do say apt-get install python-vtk -
then I will get that package and all the relevant dependencies, as
decided by the packager.  Then I will get those packages in all my
virtualenvs with ``--system-site-packages``, past and present, which
might change their behavior.  So I can't easily do evanescent installs
of these packages, as I can with the wheels / virtualenvs approach.

See you,


More information about the Neuroimaging mailing list