[HN Gopher] Escaping from Anaconda's Stranglehold on macOS
___________________________________________________________________
Escaping from Anaconda's Stranglehold on macOS
Author : surprisetalk
Score : 75 points
Date : 2024-08-29 08:57 UTC (3 days ago)
(HTM) web link (paulromer.net)
(TXT) w3m dump (paulromer.net)
| kamma4434 wrote:
| I'm not sure about what the problem here is. If the target user
| cannot be bothered to learn about "the shell" why should they
| care about the Python vendor? And the procedure shown is not easy
| peasy for a newbie.
| stackghost wrote:
| TFA is for students who are (presumably) very early in their
| programming careers.
|
| Python is often billed as a good language for beginners because
| it does not require the author to keep track of curly braces or
| line-ending semicolons, and it lets the author focus less on
| syntax and more on reasoning with code.
|
| Wouldn't it be nice if the beginner could focus on learning
| Python instead of having to learn stupid minutiae that only
| exist because we're still trying to maintain backwards
| compatibility with the VT220?
| kamma4434 wrote:
| But you _can_ learn Python with Anaconda. At the point you
| are sophisticated enough to outgrow it, wouldn't you be
| better offering a drink or two to your sysadmin friend and
| have them fix it?
|
| As an analogy- It may be just as easy to do, but I'll never
| bother to change the spark plugs in my car - I'll have
| someone knowledgeable do it. Do I think it's hard? No. Do I
| think I have better ways to spend my time? I do.
| freehorse wrote:
| Is dragging and dropping the .zshrc file the easiest way to
| run anaconda on a mac? It sounds incredibly inconvenient to
| me, and considering it is intended for people who are
| clueless about terminal and .zshrc, it may result in a mess
| with different .zshrc versions in case one installs anything
| that runs through terminal and changes .zshrc, which can be a
| lot of things.
| gkfbn wrote:
| At some point they'll have to learn about the file system,
| shell, network. Otherwise there is little point in learning
| Python.
|
| Octave, Matlab, Mathematica, Julia, R are superior for small
| programs with just a couple of functions.
|
| Escaping the stranglehold of Python would be the next
| project!
| OldGuyInTheClub wrote:
| Well said. I am grateful that my employer licenses Matlab,
| Simulink, and a lot of toolboxes and blocksets. The IDE and
| especially the documentation help me get stuff done. We've
| had waves of Python as a Matlab killer first with Enthought
| and then Anaconda as the repository. I gave Python an
| honest try but was spending all my time searching for help
| on package after package with poor to no documentation and
| trying to debug code with substandard tools.
| zelphirkalt wrote:
| Matlab is a categorical loss due to its proprietary
| character, R debatable, Julia, maybe yes. Octave, while at
| least not proprietary, still surely not, if the task is
| anything but some matrix multiplication or matrices using
| program.
| stackghost wrote:
| >At some point they'll have to learn about the file system,
| shell, network. Otherwise there is little point in learning
| Python.
|
| Sure, but I would argue that overwhelming someone with all
| those topics _at the beginning_ is counterproductive.
| 42lux wrote:
| Probably because of anacondas licensing change...
| mattl wrote:
| This seems like a lot of work to bypass something in the zshrc
| file vs. doing something in a terminal emulator? I would assume
| Python developers are somewhat forced to use a command line
| anyway.
| cowsandmilk wrote:
| As described on https://docs.python.org/3/using/mac.html ,
| python on MacOS both ships with an IDE and the ability to run
| scripts without using the command line.
| adolph wrote:
| Anaconda's hidden license for institutions is a dark pattern time
| bomb for scientific computing.
| williamstein wrote:
| Can you elaborate? Is there a link?
| kanche wrote:
| A news on the same: https://www.theregister.com/2024/08/08/an
| aconda_puts_the_squ...
| sunshowers wrote:
| > use by individual hobbyists, students, universities, non-
| profit organizations, or businesses with less than 200
| employees is allowed, and all other usage is considered
| commercial and thus requires a business relationship with
| Anaconda
|
| Wow this is so deliberately ambiguous about universities
| with more than 200 employees. Shameful.
| nmstoker wrote:
| But this doesn't apply to miniconda if you use the channel
| conda-forge, so I'm not sure there's much need for a fuss
| here.
|
| source: https://www.anaconda.com/blog/is-conda-free
| chunkyks wrote:
| We've been hit by this.
|
| When I talked to them four years ago, they agreed we were good
| to use it for free, no problem.
|
| The dollar figure they're asking for would make it the single
| most expensive software product we would be licensing in our
| enterprise, by a lot. The deadline is absurdly soon for such a
| big deal. And they opened discussion in an incredibly hostile
| manner and have made no attempt to work with us.
|
| So, I'm helping lead the effort to completely purge them from
| our ecosystem. On the one hand, I'm sad because their stuff is
| pretty good. On the other hand, their behavior is bad and the
| product isn't better by the amount they're asking for.
|
| Good riddance.
| adolph wrote:
| > And they opened discussion in an incredibly hostile manner
| and have made no attempt to work with us.
|
| With $$ for unlicensed period too?
| fhdsgbbcaA wrote:
| Clickbait title ("stranglehold", really?), and also really bad
| advice.
|
| Terminal can be scary, but "open terminal from
| Applications/Utilities" and typing "rm ~/.zsh" is objectively
| easier. Also that's not even the best solution, just a far better
| way to do this solution.
| striking wrote:
| It sounds like they want to be able to restore it too. And the
| Terminal is harder to use than a graphical step by step guide.
| fhdsgbbcaA wrote:
| This guide requires holding down arcane secret key
| combination, this is not remotely normal way to do anything,
| and prevents people from learning basic system commands every
| programmer needs to know.
|
| Also, "mv ~/.zsh ~/zsh-anaconda".
| g8oz wrote:
| His audience is not programmers.
| fhdsgbbcaA wrote:
| It quite literally is for students learning Python.
| cowsandmilk wrote:
| He is an economics professor, not a CS professor. His
| students may be going into jobs that require programming,
| but that doesn't mean they are "programmers" or that the
| purpose of the class is to teach Python.
| drozycki wrote:
| Pythons and anacondas are snakes which catch and kill their
| prey by strangling them and inducing cardiac arrest. It's a
| pun.
| fhdsgbbcaA wrote:
| Come on, putting "macOS" and "stranglehold" in a title is not
| merely a (bad) pun; it plays into article titles which adhere
| to common complaints, and topical complaints about
| macOS/Apple specifically, in a clickbaity way.
| m4rtink wrote:
| Indeed, it is high time for a new Fedora installer for Macs, the
| Anaconda monopoly needs to be broken! ;-)
| brewmarche wrote:
| You can just keep Anaconda and just use it as a pyenv
| replacement, e.g.: conda create -n "myenv"
| python=3.8 conda activate myenv
|
| Then just use pip in your environment, if you don't like conda
| packages. Not sure what the paragraph about being able to install
| multiple Python versions after getting rid of Anaconda is about.
| ok123456 wrote:
| I had to do this, using Anaconda as a pyenv replacement,
| because I worked with people with many levels of IT
| bureaucracy. They couldn't just go to python.org, download an
| official release, and use it within their user profile. They
| were only allowed to use Anaconda because it was on a list of
| approved software.
| brewmarche wrote:
| Same here. It's not that bad of a solution when you think
| about it.
| rubslopes wrote:
| Anaconda (and miniconda) is a very good solution if you
| need a container-like environment. I can easily go back to
| old projects with different python versions and do
| maintenance in them with no hassle.
| ok123456 wrote:
| pyproject.toml is a better solution
| okanat wrote:
| Does it handle binary dependencies and Python ABI changes
| well? Does it isolate them from almost the entire
| operating system? Conda does those.
|
| Conda packages compiled such that the search paths of the
| binaries are not using the OS's (which why the Linux DE
| Qt theme doesn't work for Spyder).
|
| Conda also comes with well optimized binaries for high
| performance compute which is absolutely a must for modern
| data science.
| viraptor wrote:
| That's installing another 3.8 rather than using the system one,
| isn't it?
| brewmarche wrote:
| Yes, you can specify any Python version available in the
| official channel: https://anaconda.org/main/python/files
|
| If you have license issues with the official Anaconda repos
| (talked about in other comments), switch to the conda-forge
| channel instead, it doesn't have these restrictions:
| https://anaconda.org/conda-forge/python/files
| tkuraku wrote:
| This would be the sane advice.
| cowsandmilk wrote:
| No, because half the students in your 200 person class don't
| have anaconda installed and now you are managing students in
| yet another state of python environment management with TAs
| who are economics grad students, not python experts
| Q6T46nT668w6i3m wrote:
| Nobel laureate Paul Romer sharing some Python advice is a little
| strange!
| magnio wrote:
| Whatever project solves Python dependency management deserves
| to get a Nobel in Economics for saving humanity billion of
| hours per year.
| zelphirkalt wrote:
| Usually I simply use pip and poetry. Haven't run into an
| issue in a long time. Privately I use Guix often, when it has
| the required packages. I find the dependency management
| mostly to be already solved. Perhaps I am not riding along
| the edge enough, to see things broken.
| pnt12 wrote:
| Poetry does a lot of good stuff: lock file, dev
| dependencies (and other customizable groups), easy to use
| virtual env, dependencies pulled directly from git.
|
| I do not recommend pip in serious projects, as it lacks the
| above. Here's things that I've seen:
|
| - add dependencies and not save them in the requirements
| file - forget to activate cenv and install packages
| globally - different package versions across deployments
| due to absence of lock file - main dependencies mixed with
| dev dependencies
| kevin_thibedeau wrote:
| Pip has gone down the shithole with its preaching about
| venvs. It's _my_ computer. I 'll install to site-packages
| if I damn well want to.
| zelphirkalt wrote:
| What I usually do is make a venv using pip, then use that
| venv to install poetry in it, because I don't want to
| clutter my system with outdated poetry package. Then use
| Poetry to install packages inside the venv. So the pip
| part is merely for bootstrapping.
| nextos wrote:
| I collaborate with people that use macOS while I use Linux. For
| reproducible environments, Nix has served us well.
|
| Despite the myth, it is not hard to _use_ unless you need to
| package something complicated or messy. Then it may become hard.
|
| The advantage of Nix is total version reproducibility and
| declarativeness. It's quite reassuring to know things are exactly
| the same on all computers.
| zelphirkalt wrote:
| I am fully on board with having reproducible declarative
| setups, line Nix or Guix offer. I want to note though, that the
| versions and original code may be the same, but it can still
| happen that something behaves differently on another OS. The
| code of some version of a package can intentionally do things
| differently on another OS. So you are not 100% safe from MacOS
| disturbing things.
|
| I wish though, that at my job people were as far as using Nix
| oder Guix though. Still a long way off of that. Wish people
| would explore more on and off the job, to realize the
| potential.
| nextos wrote:
| Sure, but if you run the same Nix flake on two macOS machines
| with the same architecture, it will have the same behavior.
|
| Most of package managers don't offer that guarantee. Only
| Guix has a similar level of assurance?
|
| Nix openly recognizes outputs are different per platform,
| x86_64-linux is different from aarch64-darwin. Impossible not
| to, as ultimately architectures may behave differently.
| mplanchard wrote:
| What we did at our job was I set up a nix config for myself,
| because I wanted it. When new people onboarded, they had two
| options: install this list of software or install nix and
| it'll all get installed automatically. Enough people chose to
| use the nix config over time that it became the de facto
| standard.
| hamandcheese wrote:
| I like this strategy. Nix can be tricky to explain, so
| sometimes showing is much easier than telling.
| hamandcheese wrote:
| Although Nix seems to be becoming more mainstream, I still
| have yet to encounter a (forgive me for lack of a better
| word) normie that uses it.
|
| I feel somewhat blessed that I get to work on tools at a
| company that can support a dedicated tools team. We are free
| to use the best tool for the job without needing to worry
| about popularity contests, and nix has truly been a game
| changer for us.
| lijok wrote:
| It's not a myth, Nix is incredibly complicated to get into and
| is actively hostile towards its users with the abysmal DSL and
| documentation. Every company we've tried to introduce it in has
| failed to adopt it primarily due to its incredibly steep
| learning curve
| mplanchard wrote:
| It is quite complicated to understand or to set up, yes, but
| I agree that it is easy to use. We use it at work for our dev
| environments. Like two or three of us are able to actually
| add packages, adjust nix configs, etc. Everyone else just
| runs `direnv allow` and automatically gets everything they
| need to build and run out software.
| okanat wrote:
| If you don't have enough manpower who can control and
| collaborate on the development of the environment, the
| project will not succeed to be adopted.
|
| Programming language-specific dependency tools succeeded
| due to their user friendliness, however abysmal they are in
| multi-language / OS dependent environments (and I despise
| them for that reason). Cargo.toml, go.mod, conan.txt,
| Dockerfile etc. all are can be understood by basically all
| members of a dev team. You cannot say the same for Nix for
| most devs in a team.
| bsder wrote:
| > It is quite complicated to understand or to set up, yes,
| but I agree that it is easy to use.
|
| The problem is that everything works--until it doesn't. And
| then nobody knows how to fix it.
|
| You wind up needing a single person who serves as local
| "nix tech support" who then hates life because he's a high
| end devloper dealing with nix n00bs all day long.
| rfl890 wrote:
| Avoiding sh overcomplicates this. Just give them a one liner: mv
| ~/.zshrc ~/._zshrc and vice versa. Pasting a cmd is not rocket
| science.
| giantrobot wrote:
| Man you say that but many people simply do not understand that
| a command even is. They don't know to hit return after pasting
| or how much of the command to copy. Or they'll paste it in a
| text editor.
|
| There's just a lot of people that did not grow up using
| computers the same way as many here. Whether it's they grew up
| on mobile devices or have only ever used a GUI.
|
| I don't think it's reasonable to expect a developer to _not_
| understand command lines but plenty do not. There 's whole
| populations of very junior programmers that have zero
| experience on the command line. Hell I know people with decades
| of Unix experience that don't know basic CLI stuff or reach for
| the GUI to install packages or manage things.
| bpmooch wrote:
| then they need to stop what they are doing, and learn how to
| use the system they are running first. there's no value in
| skipping ahead of basic "power user" learning for your
| preferred os. if you can't run basic commands, you dont' need
| to be writing python programs. if your educational
| institution is not providing you basic knowledge on how to
| use windows, macos, or linux, they are unfortunately failing
| you.
| okanat wrote:
| This PoV of software is why Excel (or Microsoft products in
| general) almost always wins against any database or
| specialized tool for creators, engineers, accountants
| alike.
|
| macOS (and the entire Unix universe) is a shitty
| environment for people who rarely / don't need terminal but
| whose job could be improved by a lot if a scripting
| language is used.
|
| Microsoft used to champion intermediate users who need more
| power than mindlessly clicking web pages. They are now
| turning their products yet another copy of the other
| systems where you are presented with a cliff as the
| learning curve.
|
| I disagree completely that a simple programming environment
| should require terminal access. Terminals are unforgiving
| for mistakes that a beginner makes. Most of the terminal
| capabilities should be done in GUIs. One should be able to
| access all files, edit them, change the OS environment
| variables and create programming projects in GUIs. We
| achieved that in 90s already. Why should we go back?
| sweeter wrote:
| This is insane lmao. Why not just edit out the line that added
| into your .zshrc (or by extension the .bashrc) instead of running
| through all these complicated GUI specific things just to
| basically rename the file so that ZSH doesn't load it when it
| runs a shell???
|
| This is _exactly_ why you should learn to use your tools
| properly, learn just a tiny tiny tiny bit of posix shell (which
| works for ALL posix shells sh, tcsh, bash, zsh etc...) so that
| you can understand what the heck is going on.
|
| Like seriously, this is day one stuff. Your shell loads a
| configuration file and you can set programs to run on start, or
| configure shell options, set aliases etc... This is nuts man.
|
| in fact I was so baffled that I wrote my own article response
| https://sweetbbak.github.io/post/response-to-mac-anaconda/
| easeout wrote:
| While I agree in principle, this is a professor sharing as
| foolproof a method as he can find to get many students, whose
| existing knowledge, setup, and CLI avoidance he can't control,
| to the meat of the course experience he has designed for them.
| Zigurd wrote:
| As expected, I see comments here like "Avoiding sh
| overcomplicates this." It's true. I found the shell-avoiding
| instructions no better, and possibly worse, than shell commands.
|
| But: what's sauce for the end user goose is sauce for the
| developer gander. Developers are users. Give developers good
| visual tools. Sadly I don't think there is a visual front end to
| git,, for example, that is any good among the handful I have
| tried and the dozens that attempt to make git safe, discoverable,
| and visually obvious.
| mplanchard wrote:
| Wish there was something like magit outside of emacs that I
| could recommend to people.
| 3np wrote:
| tig?
| progmetaldev wrote:
| This may be a backwards way to go about it, especially with an
| end goal of learning Git, but I feel that having learned
| Mercurial first helped me to more easily move to Git.
| Ultimately, it was using BitBucket's Mercurial repositories,
| and then Atlassian stating they were discontinuing Mercurial
| that forced me to jump to Git. Wanting to keep my Mercurial
| history forced me to learn parts of Git that I otherwise
| probably never would have touched. It seems Git has (at least
| for the present and near future) won the SCM wars for
| popularity. Working with mostly front end developers unfamiliar
| with code tools made me the go to guy at work, so I had no
| choice but to learn as much as I could about handling
| conflicts, as well as things most people rarely think about
| like a project's .gitignore and .gitattributes
| mikae1 wrote:
| The truest XKCD ever:
| https://imgs.xkcd.com/comics/python_environment_2x.png
| sonofhans wrote:
| This is really elegant. What a nice solution; single-step and
| reversible.
|
| It's also excellent documentation, written by someone who clearly
| knows their audience. It keeps all operations in GUI-land, which
| most users consider more safe. It avoids almost all technical
| explanations.
|
| Folks responding with "Terminal is easier" are missing context.
| You're not the audience. The fact that you can come up with seven
| solutions for this proves that :)
| lxgr wrote:
| > It keeps all operations in GUI-land, which most users
| consider more safe.
|
| Which is unfortunately exactly what enables so many tech
| support scams, so I'm not sure it's a pattern worth
| reinforcing.
|
| In addition to that, while it might still be helpful for
| completely non-technical users, I really don't think "avoiding
| the terminal and edits to files" is a desirable goal for anyone
| studying either Python or data analytics.
| sonofhans wrote:
| Notoriously, people get to desire their own goals, and
| there's little that we can do about it. Plenty of people
| desire to learn and use Python without the terminal. That's
| 100% possible in a professional environment today, never mind
| a classroom.
|
| Most people learn computers because they want to get better
| at a task, like programming. The point of this post is to
| help people get unstuck so they can begin learning at all.
| Adding more gates in front isn't going to help.
| latchkey wrote:
| "If you teach a course that requires Python"
|
| "Many of these students have not used the command line."
|
| I'd suggest that we are failing to teach students learning to
| code, the basics of how to use computers. Pre-requisite should
| be a class on how to use the command line.
| atoav wrote:
| I thought a class of entirely non-tech art students how to
| use the commandline to run their python code within an hour
| and that includes distractions like people using multiple
| different operating systems and explai ing how paths work on
| each. Tech inclined students get the gist of the whole thing
| in less than 15 minutes.
|
| The CLI is literally just: You write a command and a thing
| happens. That isn't a thing that people get hung up on. The
| main weirdness you need to tell them about is how to
| select/copy/paste and use the history. Throw in a lesson
| about how paths work. Sure the commands need to be remembered
| but for a start you basically just need pwd, cd and
| python/python3.
|
| You are not doing your students a service if you try to teach
| them programming by shielding them from anything that could
| give them a feel for the systems they develope for.
| crooked-v wrote:
| If anything I think a pure CLI environment would be easier
| for a lot of people than the incomprehensible skeumorphism-
| less jumble of controls that a lot of GUIs have turned
| into. Everything is built in text and done one command at a
| time, so there's much less mystery compared to trying to
| figure out what's even a button or not.
| II2II wrote:
| I suspect it depends upon the person. Plenty of people
| have difficulty remembering commands, and only the clever
| ones in that population will create a cheat sheet to help
| them along until they do remember them. On the other
| hand, they may have no trouble remembering where
| something is or what it looks like.
|
| That said, I do resent people who claim CLIs are harder
| because of that. What works for one person may not work
| for another.
| simonw wrote:
| A lot of students arrive at university these days without
| understanding what files and folders are:
| https://www.theverge.com/22684730/students-file-folder-
| direc...
| bwanab wrote:
| Most of the kids the author is talking about aren't going to
| ever code for a living - they're going to code to get their
| job done. It's a very different mindset.
| latchkey wrote:
| By that logic... we might as well stop teaching math
| because kids are never going to become mathematicians.
| exe34 wrote:
| are you thinking arithmetic, trigonometry, geometry,
| analysis or statistics?
| mistrial9 wrote:
| statistics is not mathematics -- real
| kstrauser wrote:
| Never took it, huh.
| mihaaly wrote:
| Unluckily this inability of seeing with each others' eyes - and
| the unwilling to do so: 'it is easy!' kind of never asked for
| flow of oppinions, ... daaaa, it is always easy AFTER you know
| that -, this inability makes the software products that damn
| shitshow for the user.
|
| Beyond the attention seeking 'tips of the day' kind of popups
| in random places and stages that derails you all the time (I
| mean: ALL the time) but at least so tiny little fragments of
| wisdom that you reamin the same clueless, well inside the error
| of measurement in cluelesness. Only good for putting The
| Product into the focus (Am I nice, eh? What a cool feature I
| have, eh?! Brilliant am I, eh?!) instead of the need of the
| users.
| chuckadams wrote:
| The audience is people learning a programming language. It's
| too much to ask of them to open up a file written in a
| different programming language and comment out a single line?
| Gimpei wrote:
| My takeaway from this article is that Paul Romer doesn't know how
| to use the environment feature in anaconda. If he has a problem
| with dependency resolution speed, 'conda install mamba' will
| solve that.
|
| But really, for his use cases, he should be using Julia (for DSGE
| modeling) or else R for stats.
|
| Still, I applaud his willingness to try new things, if more
| economists were like him, we might finally break the stranglehold
| of stata and matlab in econ.
| markhahn wrote:
| reminds me of instructions for using curl|bash.
|
| do people really want to do things they don't understand at all?
| apetresc wrote:
| > 10. What Changes When You Are Free
|
| > You will not be forced to work inside something known as a
| "virtual environment."
|
| Oof, this terrible advice cancels out an otherwise reasonable
| post. Beginners who don't know what they're doing are the _last_
| people who should be `pip install -r requirements.txt`-ing into
| the system Python the way this article is recommending. That 's
| not only going to make working on multiple projects nearly
| impossible (especially for the kind of beginning students who get
| recommended Anaconda, which are almost always the Data Science-y
| crowd using NumPy, Pandas, Scikit, etc, which are notoriously
| finicky with version conflicts), but it stands a good chance of
| breaking other Python-based system utilities in completely opaque
| ways. This sort of advice can fubar a naive user's entire
| workflow.
|
| I know virtualenvs suck to explain to people, but in my opinion
| it needs to be done before you ever tell them about `pip
| install`.
| dumbo-octopus wrote:
| Yes. I recently had to debug my gf's entire work computer setup
| getting fubar'd from installing a pip package at a user level
| that conflicted with the name of some package used internally
| by the 10k+/seat/year software the company devices have
| installed. Proximal cause? The installer "helpfully" failed
| over to installing at the user level when she didn't have
| permissions to write to the place she told it to. Root cause of
| course is that million dollar fancy fancy enterprise software
| somehow being unable to give itself an isolated python package
| namespace, or provide any relevant errors when conflicts
| occurred.
|
| The python packaging system has to be used in case studies of
| worst design decisions of all time.
| adolph wrote:
| > package used internally by the 10k+/seat/year software the
| company devices have installed
|
| Sounds like a skill issue that shouldn't be seen in
| "10k+/seat/year software." I wonder what other fails are in
| it.
| dumbo-octopus wrote:
| Well it constantly crashes and requires every shop to
| develop their own half-broken way of interfacing between it
| and other industry-standard software, but at least ~half
| the pixels you've seen in any modern movie or tv show have
| been touched by it at one point or another. So that's
| interesting.
| geysersam wrote:
| Thats extremely fascinating. What's it used for?
| hkdfgdfg wrote:
| I have never broken my Python installation on Windows (official
| installer) despite recklessly installing anything. If I had
| broken it, I would have just uninstalled and reinstalled.
|
| While not familiar with macOS (topic of this article), I think
| the Mac installer works the same.
|
| On Debian of course you can cause great damage because the
| system Python is used for critical system functions. This is
| silly, I think the system python should be an isolated install
| in /usr/sbin. Better yet, move back to Perl for the system.
| rbanffy wrote:
| You won't break a machine by installing Python packages on an
| OS that never uses Python for anything.
| abdullahkhalids wrote:
| I teach using python. You should try explaining virtual
| environments to students, most of them with no programming
| experience, or any real notion of the state of a computer
| system. I do, because we recommend students use them. Every
| class consists of endless debugging of student systems.
|
| After that you might understand the OP's viewpoint.
| puppycodes wrote:
| I always appreciate a post about a simple fix to a problem a lot
| of folks run into thats not esoteric and lays it out simply :)
|
| As engineer of many many years now all I can say with certainty
| is that confusion, failure, research and eventually small
| successes have been the central theme of working with computers.
| I personally love the struggle and mystery but its not for
| everyone. At the end of the day its about what you want to get
| out of it. If you want to write programs without learning about
| the terminal go for it, but I would say there are better gilded
| cages with GUIs that help you get a lot more done within that
| constraint.
|
| If you want a deeper understanding, I think its more helpful to
| admit you can't cheat the process of learning. Slow is the only
| speed.
| zjp wrote:
| I still don't really get what conda is or does. AFAIK it ensures
| ABI compatibility between Python packages that have C extensions?
| Does manylinux and the limited API not take care of this?
| adolph wrote:
| Way back Anaconda was an accessible way to get Numpy running
| without having to scrounge up a Fortran compiler for one's
| MacOS version.
| farhanhubble wrote:
| This is typical solve-one-problem-with-another approach. Anaconda
| may be bloated but it is really straightforward to use from the
| navigator and yes you can have many different Python environments
| installed at the same time.
| byyoung3 wrote:
| cant you just do 'conda deactivate' until its gone?
| rbanffy wrote:
| I'm so happy with MacPorts I find all this discussion weird.
|
| True, MacPorts isn't the official Python installer, but macOS
| doesn't have an official Python anyway.
___________________________________________________________________
(page generated 2024-09-01 23:00 UTC)