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

261–270 of 286 posts

Re: Escaping from Anaconda's Stranglehold on macOS

#261

Post by promer »

bardan wrote: post #198
promer wrote: post #155

I appreciate all the comments. I agree with most, even when they disagree with me or each other. I especially agree with the questions several people raise: What it is that we should teach? In which order? I think there is a consensus about what a student should end up knowing. Even if they are not going to become developers, they should be able to edit text files; they should be able to run commands from the termina…

If they are unable to use a shell, don't understand environments etc. I would push them onto some specific IDE/plugin combination that creates a new virtualenv, handles PATH etc. for every new project. Dealing with environments and understanding how different parts of the filesystem relate to each other is its own pretty steep learning curve. You wouldn't want them to get tripped up on that while they are learning to…

One suggestion that someone endorsed in another comment is to use VS Code. This would not be my preferred choice, but it would be useful to run an experiment in which students who are new to code start by installing it and following its suggestions about how to configure a working environment. One advantage with this approach is that it introduces students to a text editor.

A second alternative is the Idle environment that is included with every official install of Python from python.org. I have not used it much and I've never tried to teach a course with it. But it comes from the most trustworthy source in this complicated environment.

I'd be very interested in hearing about experience using these to start learning from the very beginning or using them to teach a course for people who are just getting started.

Re: Escaping from Anaconda's Stranglehold on macOS

#262

Post by promer »

swiftcoder wrote: post #202
promer wrote: post #176

Earlier quoted context omitted.

I don't see how it could be correct to say that I'm recommending that students pip install into the system Python. On macOS, there hasn't been a system Python since 12.3 came out in Jan of 2022. And as far as I know, there was never a system Python on Windows.

> On macOS, there hasn't been a system Python since 12.3 came out in Jan of 2022 It may not be pre-installed, but if you install Xcode it will also install python3 in /usr/bin/ for you...

The assertion that seemed incorrect was that I was recommending an option that would install libraries to the system Python.

Xcode does put a binary with the name python3 into `/usr/bin`. This is not a system Python, but set that aside.

Can you explain how someone might pip install libraries to this instance of Python?

Re: Escaping from Anaconda's Stranglehold on macOS

#263

Post by promer »

brewmarche wrote: post #15

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.

> Not sure what the paragraph about being able to install multiple Python versions after getting rid of Anaconda is about.

The sentence says "install and run". The problem is with "run."

On macOS, most students who install Anaconda accept the default, which is to autoactivate the base conda environment every time someone starts a terminal session. As a result, the instructions for starting an official Python don't work.

If you use Anaconda on Windows, you will not be able to test the effects of autoactivate.

Re: Escaping from Anaconda's Stranglehold on macOS

#264

Post by promer »

fergie wrote: post #197
promer wrote: post #155

I appreciate all the comments. I agree with most, even when they disagree with me or each other. I especially agree with the questions several people raise: What it is that we should teach? In which order? I think there is a consensus about what a student should end up knowing. Even if they are not going to become developers, they should be able to edit text files; they should be able to run commands from the termina…

Are you familiar with Software Carpentry? If so, what do you think about it? -> https://www.ub.uio.no/english/libraries/dsc/carpentry-uio/

If you visit the link https://swcarpentry.github.io/python-novice-inflammation/ which offers the introduction to Python, you'll find this strange statement.

> Although one can install a plain-vanilla Python and all required libraries by hand, we recommend installing Anaconda ...

In a novice course, if the official version of Python and its tools all work, why is this organization recommending a product from a for-profit organization that requires acceptance of some complex and potentially costly provisions in its terms of use?

Re: Escaping from Anaconda's Stranglehold on macOS

#265

Post by 082349872349872 »

defrost wrote: post #256
mistrial9 wrote: post #240

Earlier quoted context omitted.

this has nothing to do with LLMs at all.. you are uninformed about the old feud between mathematics and statistics so you claim this is not true. anyway, on reflection, the word "is" does not fit here.. statistics and mathematics are not disjoint, but no, statistics is not a field of mathematics.. ask around among people with serious graduate studies in mathematics and they will fill you in.. Maybe it overlaps into t…

> this has nothing to do with LLMs at all They are plugged into the backend of many search engines these days and they excel at picking out the nature of the pattern | result that a questioner wants and feeding back what they want to hear. > ask around among people with serious graduate studies in mathematics and they will fill you in I checked in with Terence Tao who I first met at an Australian math club get togeth…

> in the mid 1980s

$\tau as \epsilon$!

Re: Escaping from Anaconda's Stranglehold on macOS

#266

Post by exe34 »

mistrial9 wrote: post #237
mistrial9 wrote: post #92

Earlier quoted context omitted.

statistics is not mathematics -- real

statistics really is not mathematics according to serious math people. It feels like "eternal September" with your replies.

are these "serious math people" in the room with you now? how do they write their statistical operators, in cuneiform?

Re: Escaping from Anaconda's Stranglehold on macOS

#267

Post by dumbo-octopus »

VHRanger wrote: post #257
jampekka wrote: post #251

Earlier quoted context omitted.

I don't see what's wrong with micropackages.

Massive attack surface. That's true as a security risk, but also as a dependency risk (eg. left-pad).

If you don’t vendor your dependencies. Which is a poor practice that is commonly associated with NPM, but is by no means a requirement of the technology.

Re: Escaping from Anaconda's Stranglehold on macOS

#268

Post by eru »

zbentley wrote: post #224
eru wrote: post #133

Earlier quoted context omitted.

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

Well, for what it's worth, Rust's linter clippy likes to warn you about using different versions of the same crate. I think the warning is mostly formulated in terms of helping you reduce compile times, but your concerns about mutability might also be justified.

Re: Escaping from Anaconda's Stranglehold on macOS

#269

Post by dumbo-octopus »

dumbo-octopus wrote: post #267
VHRanger wrote: post #257

Earlier quoted context omitted.

Massive attack surface. That's true as a security risk, but also as a dependency risk (eg. left-pad).

If you don’t vendor your dependencies. Which is a poor practice that is commonly associated with NPM, but is by no means a requirement of the technology.

Especially if…, I should say. Even vendored dependencies are a risk as NPM commits the additional sin of allowing the act of pulling a package onto the local machine for inspection to execute arbitrary code in the form of “postinstall” hooks.

Re: Escaping from Anaconda's Stranglehold on macOS

#270

Post by jampekka »

VHRanger wrote: post #257
jampekka wrote: post #251

Earlier quoted context omitted.

I don't see what's wrong with micropackages.

Massive attack surface. That's true as a security risk, but also as a dependency risk (eg. left-pad).

Review and pin your direct dependencies. With transitive dependencies it doesn't differ from trusting large dependencies in general.

The alternative to micropackages has significant downsides. Pulling in extra surface and rolling your own buggy implementations while waiting for some commitee to bikeshed years on the implementation.

Making the right thing easy rather than the wrong thing hard is a lot better approach.

Post reply on HN