Escaping from Anaconda (Python)(paulromer.net)
paulromer.net
Escaping from Anaconda (Python)
https://paulromer.net/escaping-from-anaconda/
27 comments
> I think Anaconda has caused more trouble than for what it's worth.
I concur
dumped it and never looked back
I concur
dumped it and never looked back
In our classes, we were lucky enough to have SSH access to lab machines with all the right stuff set up. But for home use, they suggested using pip, not even with venvs. Anaconda seems like overkill.
At this point I would highly highly recommend uv as the starting point for stuff like this. As of the 0.3.0 release it now handles installing python for you as well as all the regular pip stuff and venv management/setup.
https://astral.sh/blog/uv-unified-python-packaging
https://astral.sh/blog/uv-unified-python-packaging
how does this compare to rye?
Good question. They address it here: https://github.com/astral-sh/rye/discussions/1164
You'd recommend uv to python beginners? Bear in mind that the reason that many students are lured into using Anaconda is because they're still scared of the command line.
It's tricky. For non CS students, do you teach them coding in python or everything else?
IMO, it's best to set them up on their work station with everything they need to get started then as the need arises start introducing more complex concepts such as deps management, version control, python versions etc.
I always worry that we over load students when we teach them coding. It can lead to feeling overwhelmed, thinking coding is not for them and never coming near it.
So uv is not the solution imo. Bare bones python with a basic repl editor for starting out.
This is my experience from being a helper and a trainer in the softwate carpentries workshops.
IMO, it's best to set them up on their work station with everything they need to get started then as the need arises start introducing more complex concepts such as deps management, version control, python versions etc.
I always worry that we over load students when we teach them coding. It can lead to feeling overwhelmed, thinking coding is not for them and never coming near it.
So uv is not the solution imo. Bare bones python with a basic repl editor for starting out.
This is my experience from being a helper and a trainer in the softwate carpentries workshops.
> Bare bones python with a basic repl editor for starting out.
Fortunately Python already includes an basic editor in the standard distribution, IDLE. It is an underrated tool. I think one reason Ruby stalled and failed to overtake Python after an initial surge in the aughts was the lack of an similar tool leading to more attrition for beginners. See for example this 13 year-old stackoverflow question: https://stackoverflow.com/questions/3763140/idle-like-intera...
Fortunately Python already includes an basic editor in the standard distribution, IDLE. It is an underrated tool. I think one reason Ruby stalled and failed to overtake Python after an initial surge in the aughts was the lack of an similar tool leading to more attrition for beginners. See for example this 13 year-old stackoverflow question: https://stackoverflow.com/questions/3763140/idle-like-intera...
It's nice to see someone who shouldn't be seen as a programmer (Paul Romer is a Nobel-winning macroeconomist) teaching python as a matter of process in his classes.
For a long time economics was dragging behind using matlab or specialized statistics software (ugh). Even using R was considered novel among econometricians for a while.
For a long time economics was dragging behind using matlab or specialized statistics software (ugh). Even using R was considered novel among econometricians for a while.
OTOH it's sad that a Nobel-winning macroeconomist has to write a blog article about fixing Anaconda's hostile takeover of student machines and setting up a basic Python environment.
Sure, but compared to matlab or STATA it's still great news.
I mean, we dependency management in python is a complete mess. It's not something we can expect a mere Nobel winner to solve.
I mean, we dependency management in python is a complete mess. It's not something we can expect a mere Nobel winner to solve.
I'm wondering the pro's and con's of teaching Python via Jupyter Lite. It's about as sandboxed as it gets, and can't get crapped on by other software -- yet. I created some simple instructions for erasing all traces of it from your browser's data, so you can start over if you want. Those who already have working (or non-working) Python installs can keep them.
I think it supports enough stuff for things like "programming 101" or "learn Python by doing something simple with data."
Perhaps near the end of the course you can introduce the problems of grown-up Python, after the students have already mastered things like syntax and hierarchical structures.
I think it supports enough stuff for things like "programming 101" or "learn Python by doing something simple with data."
Perhaps near the end of the course you can introduce the problems of grown-up Python, after the students have already mastered things like syntax and hierarchical structures.
Why not teach students how to work with their .zshrc file and become better computer users? I've never understood the aversion in academia to teaching people how computers work. This could be "fixed" with a simple sed line or `vim/emacs/nano ~.zshrc` rather than a multi step process of dragging files around and futzing around in the UI. I see this all the time in higher ed, so much wasted time and effort coming up with long complicated procedures that appeal to people unwilling to learn the basics of computers rather than just teaching effective computing usage. Especially now in an era where computers are a tool almost everyone needs to know how to use to succeed in the workforce, it just doesn't make sense. Learning how to be effective in Unix should be a required 100 level class for almost every major by now.
This should be read in the context of the next article (https://paulromer.net/environment-as-code/) for full understanding.
That said, I'm not a huge fan of the approach described. It's leaning a bit too much on Wittgenstein's Ladder for my taste, but more importantly it's putting concepts out of order. The article seems to dismiss virtual environments as more complex, but they really aren't that bad - they're honestly easier to work with than the approach the author discovered organically, of creating "real" environments by repeatedly reinstalling Python and setting up dependencies from a requirements.txt file. This glosses over the hard part of populating the requirements.txt file, while also not building the necessary conceptual framework to understand dependency graphs (and thus lockfiles).
I was especially bothered by the fact that this advises blindly moving a file around using the GUI without trying to understand the purpose of that file, and describing what Anaconda does as "taking over the system". While I'm sure that works, if students are in the position described then they should learn fundamental developer skills first. I.e.:
> There is a lot to learn when you are getting started. Try out virtual environments later, when you are ready. If you do not know how to edit a file, run a command from the terminal, and have pip install libraries from a requirements.txt file, you are not ready.
It takes mere minutes to learn these skills, and they should have been taught way before exposing the student to anything that actually justifies setting up Anaconda. There are countless interesting projects for students that don't require third-party libraries at all, let alone the SciPy stack (and even that installs just fine with Pip nowadays anyway).
It's also indefensible, IMO, to say:
> python3.11 and python3.12 are examples of major versions.
> python3.12.4 and python3.12.5 are minor versions.
While I understand the impetus ("Python 3 is the brand now"), this is simply incorrect, and incompatible with how every relevant extant piece of documentation uses the terms (including for tools like Pip that will immediately become relevant to the student).
That said, I'm not a huge fan of the approach described. It's leaning a bit too much on Wittgenstein's Ladder for my taste, but more importantly it's putting concepts out of order. The article seems to dismiss virtual environments as more complex, but they really aren't that bad - they're honestly easier to work with than the approach the author discovered organically, of creating "real" environments by repeatedly reinstalling Python and setting up dependencies from a requirements.txt file. This glosses over the hard part of populating the requirements.txt file, while also not building the necessary conceptual framework to understand dependency graphs (and thus lockfiles).
I was especially bothered by the fact that this advises blindly moving a file around using the GUI without trying to understand the purpose of that file, and describing what Anaconda does as "taking over the system". While I'm sure that works, if students are in the position described then they should learn fundamental developer skills first. I.e.:
> There is a lot to learn when you are getting started. Try out virtual environments later, when you are ready. If you do not know how to edit a file, run a command from the terminal, and have pip install libraries from a requirements.txt file, you are not ready.
It takes mere minutes to learn these skills, and they should have been taught way before exposing the student to anything that actually justifies setting up Anaconda. There are countless interesting projects for students that don't require third-party libraries at all, let alone the SciPy stack (and even that installs just fine with Pip nowadays anyway).
It's also indefensible, IMO, to say:
> python3.11 and python3.12 are examples of major versions.
> python3.12.4 and python3.12.5 are minor versions.
While I understand the impetus ("Python 3 is the brand now"), this is simply incorrect, and incompatible with how every relevant extant piece of documentation uses the terms (including for tools like Pip that will immediately become relevant to the student).
Calling 3.11 vs 3.12 a major version change is incorrect in orthodox semantic versioning terms.
However, for python, it makes sense. A bunch of code breaks in 3.12 vs 3.11, for instance. Also, python 2 vs python 3 are very incompatible at this point, and it's been a split over a decade old.
However, for python, it makes sense. A bunch of code breaks in 3.12 vs 3.11, for instance. Also, python 2 vs python 3 are very incompatible at this point, and it's been a split over a decade old.
Spoken like someone who has never had to teach non-programmers from complete scratch. Yes it would be ideal to spend hours setting up the conceptual framework for environment management. But now you’re teaching a “Python conceptual frameworks” course instead of whatever you were originally supposed to talk about (usually some specific package or workflow). It’s liable to be frustrating and feel irrelevant for people who are not and will not be career programmers. Better to get going quick and circle back around to that stuff if/when necessary and it’s properly motivated.
This is why R actually really great btw, R/RStudio make it insanely easy to “just get going” with a package installer UI.
This is why R actually really great btw, R/RStudio make it insanely easy to “just get going” with a package installer UI.
Agreed this is why R up take is so high compared to python in non CS fields. But I've seen people quickly hit a bottleneck of deps hell and flounder because the tools RStudio provides are (imo) not great. Posit (Rstudio) was too heavily invested in their IDE. I'm glad to see them branching out into (see their up coming ide positron).
yes, number 1 reason why the researchers around me pick R. RStudio just works.
I had to run someone's 10 year old R workflow last week. Ran perfectly.
Last years python code will not run unless someone was careful enough to make a requirements.txt. Try explaining that to the non computer scientists. My python support colleague runs into that constantly. She is not a happy support person.
I had to run someone's 10 year old R workflow last week. Ran perfectly.
Last years python code will not run unless someone was careful enough to make a requirements.txt. Try explaining that to the non computer scientists. My python support colleague runs into that constantly. She is not a happy support person.
Same with NodeJS. The way it does package management is more "Pythonic" than Python. Even importing your own files is simpler, just relative paths instead of the __init__.py and packages.
I still find it useful to describe some things as "taking over my computer," or in other terms, "I don't fw that." Sure I can if I need to, but I have more important things to take care of. This is why Python projects come with Dockerfiles.
Thanks for pointing out this error.
You are correct that the post misused the terms major version and minor version.
I'll fix it, and note the error and your catch, because
- I don't want to spread misinformation; and
- the right thing to do is to acknowledge the contributions that others make.
You are correct that the post misused the terms major version and minor version.
I'll fix it, and note the error and your catch, because
- I don't want to spread misinformation; and
- the right thing to do is to acknowledge the contributions that others make.
[deleted]
Huh, I always found Anaconda a convenient way to manage environments, and had a lot of tools I use anyway. Though I mostly use Miniconda on installs now.
[deleted]
I think that students' first real introduction to python should be through the command line, virtual environments and pip. This may hurt at first, but it'll probably be less painful than when you eventually hit a road block and have to learn how to transition away from Anaconda.