Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Escaping from Anaconda's Stranglehold on macOS

paulromer.net

Post reply on HN
Print view View original

121–130 of 286 posts

Re: Escaping from Anaconda's Stranglehold on macOS

#121

Post by jvolkman »

kevin_thibedeau wrote: post #99
zelphirkalt wrote: post #78

Earlier quoted context omitted.

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.

You shouldn't have to launch a sub-shell to run a script interpreter. That is exemplary of how nobody in the Python leadership can fix their perpetual packaging f-ups of the last two decades and are now just sticking their collective heads in the sand.

Just invoke the python interpreter from its venv path. You don't need the sub-shell.

Re: Escaping from Anaconda's Stranglehold on macOS

#123

Post by RayVR »

viewtransform wrote: post #119
RayVR wrote: post #107

What is an “official version of python”? Anaconda is a distribution, which to my understanding, includes an official version of Python. Anaconda includes its own way of doing things to solve a lot of common problems people face. Personally, I don’t use Anaconda any longer because I ran into so many issues over so many years with conda, their package manager. I’m also almost competent enough to deal with a lot of the…

What do you use in place of Anaconda ?

Homebrew, pip, venv

Re: Escaping from Anaconda's Stranglehold on macOS

#124

Post by dumbo-octopus »

geysersam wrote: post #94
dumbo-octopus wrote: post #91

Earlier quoted context omitted.

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.

Thats extremely fascinating. What's it used for?

By the books Digital Compositing, but Editors also gravitate towards it for generalist work.

Re: Escaping from Anaconda's Stranglehold on macOS

#125

Post by mistrial9 »

kstrauser wrote: post #97
mistrial9 wrote: post #92

Earlier quoted context omitted.

statistics is not mathematics -- real

Never took it, huh.

two second search -- "Statistics is considered a mathematical science that is distinct from mathematics, though it does use mathematical methods:"

"statistics arguably is not a branch of mathematics. It is a mathematical science, built upon the mathematical discipline of probability. Some ways in which mathematics and Statistics differ include: Statistics often does not produce definitive conclusions whereas mathematics usually does."

Re: Escaping from Anaconda's Stranglehold on macOS

#126

Post by ericjmorey »

mkl wrote: post #114
adolph wrote: post #4

Anaconda’s hidden license for institutions is a dark pattern time bomb for scientific computing.

Miniforge [1] provides almost all the same benefits and features without the licensing headaches. The commercial/sign-up nagging is gone, and the GUI launcher is the only thing I've noticed is missing, but I don't use that as it's extraordinarily slow. [1] https://github.com/conda-forge/miniforge

Pixi takes it a step further and provides for project management rather than just environment management.

Re: Escaping from Anaconda's Stranglehold on macOS

#127

Post by ok123456 »

okanat wrote: post #68
ok123456 wrote: post #61

Earlier quoted context omitted.

pyproject.toml is a better solution

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.

Use docker/podman if you are worried about ABI changes and isolating them from the entire operating system.

Most people's problems getting their Python toolchains to work optimally are caused by using operating systems that don't come with build utils. That's a cultural problem solved by using an operating system with a culture of distributing those tools.

Re: Escaping from Anaconda's Stranglehold on macOS

#128

Post by ericjmorey »

chunkyks wrote: post #48
adolph wrote: post #4

Anaconda’s hidden license for institutions is a dark pattern time bomb for scientific computing.

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,…

Just switch to pixi.

Re: Escaping from Anaconda's Stranglehold on macOS

#129

Post by zbentley »

BugsJustFindMe wrote: post #112
apetresc wrote: post #69

> 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 proj…

> I know virtualenvs suck to explain to people, but in my opinion it needs to be done This is because Python doesn't have versioned imports, which means you can't have multiple versions of the same package in the same environment, but I like to dream about a world where this isn't the case. If instead of import foo we had import foo@x.y.z#optional-checksum, the Python world would be massively improved. It seems like…

Virtualenvs solve not having separate workspace-local package installations, not a lack of versioned imports. Versioned imports are not a good solution to separate installations of packages: code is harder to upgrade, cluttered, and encouraged to depend on specifics rather than contracts. There’s a reason every major language localizes their version pinning into a per-project dependencies file (which can be anywhere on the spectrum between “contracts only semver ranges” and “checksummed/vendored lockfile”). And that’s before considering the troublesome behaviors that emerge when you permit importing multiple versions of the same library in the same program, if you want that too.

Re: Escaping from Anaconda's Stranglehold on macOS

#130

Post by eru »

Al-Khwarizmi wrote: post #105
freeopinion wrote: post #100

Earlier quoted context omitted.

After that I wonder why people think Python is a good choice to teach as a first experience in programming. Virtual environments is actually my biggest gripe with Python. I think it is interesting to consider why Python is so popular despite such fiascos. The answers can be very informative but can also be giant red flags.

Because every option sucks for teaching. C/C++? Full of footguns. Java/C#? Too complicated for beginners. Pascal? Outdated. Etc. I personally prefer C to teach first-year CS students but just as the lesser evil. A good first programming language is sorely lacking. (Note that I'm talking about the imperative programming paradigm. The debate on whether one should start with functional programming is outside the scope o…

You can teach imperative programming with OCaml or Racket, too. :)

C is indeed pretty evil, though slightly less though with modern sanitisers, so you can get a better error message than just a segfault (or silently doing the wrong thing).

Pascal isn't really more outdated than C. Especially if you use Delphi?

Python is actually fine, you can get pretty far with just the standard library, and the libraries that you can install with your Linux distribution's package manager (eg via Pacman). I do agree that package management with Python is pretty bad out-of-the-box.

Post reply on HN