On Feb 21, 2017, at 09:30 PM, James Henstridge wrote:
>So we might be able to do a single package that can both serve as a
>runtime for other snaps and as a useful Python development
>environment.
It would be interesting to see, but my tendency is to want separate
interpreter environments for different purposes. See my previous post re: a
locked down system interpreter for /usr/bin scripts.
The problem with one-size-fits-all (and we have this problem today with
deb-based /usr/bin/python{2,3}) is that people sudo pip install all kinds of
crazy things into their {site,dist}-packages, and that can break things, which
are difficult to debug (though we're adding some useful features to 3.7 to
help with that).
So I think it makes some sense to separate these concerns: OS platform use,
confined snap application use, developer playground. Virtualenvs are the
typical "Pythonic" way of doing that, but snaps provide another opportunity
for confinement.
(Of course "/usr/bin/python{,2,3}" is the long-established ui for that
developer playground.)
Cheers,
-Barry
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
