[Neuroimaging] Technical details managing Python versions and packages.

[Matthew Brett]

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,

Matthew