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

221–230 of 286 posts

Re: Escaping from Anaconda's Stranglehold on macOS

#221

Post by jampekka »

dvdkon wrote: post #220
jampekka wrote: post #214

Earlier quoted context omitted.

What magic is there for finding node_modules? It's in the same directory as package.json. Very similar (though simpler) to how Python modules work. There's also usually one global package dir, but that's almost exclusively used for runnable binaries, and not even really needed when there's npx. If you think Python packaging has less magic, you probably don't know it very deeply. I lost all hope for Python package man…

I was talking more about the package lookup when running code, via e.g. `node script.js`. I think it looks in all parent directories of the CWD, or maybe of the script? It's not too complicated, but it is "more magic" IMO. Actually building Python packages is pretty complex, but that's the case for JS too. Java avoids this by distributing compiled libraries.

It looks up from script.js'd directory or the earliest parent with node_modules. Not CWD. A lot like "import somemodule" in script.py tries to import somemodule.py file from the directory script.py is in.

Traversing to the parent is especially nice for scripts. In python having scripts outside the module directory is quite painful.

Gyp is a lot easier than Python setup.py. The "easy" Java packages are comparable to pure Python/pure JS packages. With e.g. C bindings JNI/Java packaging is a horrid pain.

Re: Escaping from Anaconda's Stranglehold on macOS

#222

Post by pwang »

sunshowers wrote: post #19
kanche wrote: post #8

Earlier quoted context omitted.

A news on the same: https://www.theregister.com/2024/08/08/anaconda_puts_the_squ...

> 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.

I posted an update about this: https://www.linkedin.com/posts/pzwang_hi-everyone-recently-t...

TLDR - we are working to clean up this language to leave it clear that educational institutions are exempt, and that these commercial terms do not apply to third-party channels hosted at anaconda.org (which includes conda-forge).

Re: Escaping from Anaconda's Stranglehold on macOS

#223

Post by atoav »

exe34 wrote: post #208
crooked-v wrote: post #66

Earlier quoted context omitted.

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.

I don't understand the mentality myself, but some people just turn off their brain immediately if you say "command line", but somehow they see the arcane key combinations that you have to remember and do in the right sequence as more of an exciting challenge.

Well, some people or *cough* hackers feel extra special when pointing out how crazy complicated it is.

When I shown the CLI I make sure to switch white on dark text to dsrk on white text. First it is more readable that way on a projector, second people are less likely to switch their brains off. A bit like xkcds idea to make graphs look hand drawn to reach people better.

Re: Escaping from Anaconda's Stranglehold on macOS

#224

Post by zbentley »

eru wrote: post #133
zbentley wrote: post #129

Earlier quoted context omitted.

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…

> 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. Rust has versioned imports. So you can import different versions of the same module (at least in your transitive dependencies).

Yep. And while that’s not something I’d call a mistake per se, it can be troublesome. What if a crate you depend on at different versions provides access to global state? What if a transitive embeds definitions from that crate into public contracts consumed by code using a different version?

Rust offers mitigations or means of detection for those cases, but they still require thought and troubleshooting when they occur. Given Python’s lack of static typing and more-likely-to-be-nonexpert user base and usage patterns, I suspect that troublesomeness would not be a value-add for the Python platform.

Re: Escaping from Anaconda's Stranglehold on macOS

#225

Post by pwang »

zjp wrote: post #83

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?

What if you want to ensure that the same packages are available, built in a similar way, between your Mac and some linux servers? What if you need to share or ensure that your projects work between Linux and Windows? What if you are supporting a lot of less-sophisticated users across a number of different OSes, or even different versions of the same OS?

There are a ton of subtleties in the build toolchain even within a single OS type, and these will lead to downstream frustrations with packages that just bundle pre-compiled versions of C/C++ libraries.

The conda approach treats the underlying libraries as first-class citizens in the package ecosystem; tracks their interdependencies; and most packages are built in such a way that they are relocatable on your filesystem and don't require system privileges to install. conda and the various packages in the conda universe (whether official ones from Anaconda or the community-built ones in conda-forge) all make it so that this baseline hard problem is mostly solved across all major OSes, and solved in a relatively consistent way.

You can think of conda as a cross-platform, cross-architecture, multi-language, userspace package manager. It grew into this because numerical Python's package ecosystem is so horribly complex and the users span such a huge set of install environments, that conda ended up having to be a generic rpm/brew/apt kind of thing.

Re: Escaping from Anaconda's Stranglehold on macOS

#227

Post by lhfacx »

polemic wrote: post #177
nox101 wrote: post #169

Earlier quoted context omitted.

IMO what needs to happen is python needs to get rid of system installs and only work via venv. It should check the current folder for some .venv or something and auto-config itself to the current directory (or complain that you need to config with a messages like "python not configured for current folder. Run 'source bin/activate' to configure. Honestly thought that could be so much better. The entire problem of pyth…

Python developers agree. See PEP 668 – Marking Python base environments as “externally managed” – https://peps.python.org/pep-0668/

This is insane. Apparently (at least on Debian) this can be circumvented by putting this in ~/.config/pip/pip.conf:

  [global]
  break-system-packages = true
I would have preferred single-version-externally-managed to keep fond memories of setuptools alive.

It becomes increasingly impossible to track down home directory pollution and config files in Python. Next step will be a Python registry on Linux. How about:

  regedit VENV=/home/sjw/venv42 KEYWORD=single-version-externally-managed DWORD=0xbadbee

Re: Escaping from Anaconda's Stranglehold on macOS

#228

Post by lupire »

1propionyl wrote: post #175
AtlasBarfed wrote: post #109

Earlier quoted context omitted.

Python has dogshit package management that makes java look well thought out and sane.

> that makes java look well thought out and sane That's not hard. Java's package management is well thought out and sane.

Well, it's still PATH based, which is much worse than virtual environments (directory scoped) or Nix (well-versioned sharing).

Re: Escaping from Anaconda's Stranglehold on macOS

#229

Post by exe34 »

atoav wrote: post #223
exe34 wrote: post #208

Earlier quoted context omitted.

I don't understand the mentality myself, but some people just turn off their brain immediately if you say "command line", but somehow they see the arcane key combinations that you have to remember and do in the right sequence as more of an exciting challenge.

Well, some people or *cough* hackers feel extra special when pointing out how crazy complicated it is. When I shown the CLI I make sure to switch white on dark text to dsrk on white text. First it is more readable that way on a projector, second people are less likely to switch their brains off. A bit like xkcds idea to make graphs look hand drawn to reach people better.

do they? can you give an example?

Re: Escaping from Anaconda's Stranglehold on macOS

#230

Post by regularfry »

bmitc wrote: post #146
abdullahkhalids wrote: post #93

Earlier quoted context omitted.

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.

Then why teach Python? All of these issues are because Python is a ridiculously poorly designed language which is still having new features added to it. It's generally a mess.

The issues are with one particular facet of poor design and management. The rest of it is manageable, if distasteful, and worth the effort for the ecosystem (in general).
Post reply on HN