korijn

Exactly this is very reminiscent

Put yourself in a position where it is your problem/responsibility, where you cannot depend on another to do it for you. You'll be learning every day.

Inspiring article. Well written. Totally feeling it!

The ability to read is all it takes to have AGI?

There's no lockfile or anything with this approach right? So in a year or two all of these scripts will be broken because people didn't pin their dependencies?

I like it though. It's very convenient.

Are you an EU citizen?

How does this compare to dbt? Seems like it can do the same?

Is it ironic that this comment has evoked a discussion on minutiae?

Take ownership.

I will! I'm sure it's faster when the data is available. But when it's not, in the common circumstances described above, network and disk IO are still the same unchanged bottlenecks, for any package manager.

In conversations like this, we are all too quick to project our experiences on the package managers and not sharing in what circumstances we are using them.

I have worked with poetry professionally for about 5 years now and I am not looking back. It is exceptionally good. Dependency resolution speed is not an issue beyond the first run since all that hard to acquire metadata is actually cached in a local index.

And even that first run is not particularly slow - _unless_ you depend on packages that are not available as wheels, which last I checked is not nearly as common nowadays as it was 10 years ago. However it can still happen: for example, if you are working with python 3.8 and you are using the latest version of some fancy library, they may have already stopped building wheels for that version of python. That means the package manager has to fall back to the sdist, and actually run the build scripts to acquire the metadata.

On top of all this, private package feeds (like the one provided by azure devops) sometimes don't provide a metadata API at all, meaning the package manager has to download every single package just to get the metadata.

The important bit of my little wall of text here though is that this is all true for all the other package managers as well. You can't necessarily attribute slow dependency resolution to a solver being written in C++ or pure python, given all of these other compounding factors which are often overlooked.

RTFM

Well, it doesn't necessarily have to be 10 or 20 years long, all it takes is for the timeframe to overlap with a certificate being revoked, I guess. Process lifetimes of a few months are definitely not uncommon. Anyway, I can see the tradeoff. There just needs to be a mechanism to disable this performance optimization, or to invalidate the cache (e.g. periodically).

Doesn't this potentially create security problems if process lifetime is very long? Changes to the certificate store on the system will potentially not be picked up?

We should invent solutions for problems that we have, instead of wildly trying to apply this tech to everything we can think of. We are skipping the benefit/cost considerations.

What is an efficient process to avoid using versions with known vulnerabilities for long times when using a tool like stablebuild?

Are you implying leadership is not a skill that can be honed? Is being a leader not a profession?

Edit: instead of responding to individual comments, I will just edit this comment.

I am just a little bit sad about the emotional responses here on this thread, just echoing a sentiment, without much critical discourse.

Partly, yes, but do note he is still very much involved with the faster-cpython project via Microsoft. Google faster cpython and van rossum to find some interviews and talks. You can also check out the faster-cpython project on github to read more.

The very first example in the article discredits efforts to add clear communication.

Also consuming enormous amounts of power and water

Absolutely insane. When will it be enough?

Fair enough. I've attempted to reword this to be more considerate of the possibilities.

I want to add that the author's attitude can be considered prohibitive to their professional and personal growth. They are taking quite a strong position (blogging about it emphasizes how much this matters to them) which could have the unintended side effect of discouraging peers and managers from honestly giving them feedback on the situation.

Edit: I've reworded this to be less black and white. The down-voting here does exemplify the argument that negative feedback is not appreciated.

I think this doesn't solve the real problem: every person will categorize a document differently and look in a different place. That's the hard part. Creating categories and uniquely identifying them is easy.

For some, this is indeed crucial. But there are plenty of people who are receptive to effective communication regardless of title.

I guess the thing that stands out to me is that this story shows the value of managers. John is obviously more experienced in dealing with emotional people (we are all that person sometimes).

For me, I read code instead of docs when I need to understand a dependency or tool better. That gives me direction and focus when reading code. You learn a lot from the process.

Check out keycmd[1], you might appreciate the ideas there. Disclaimer: it's my project.

[1] https://github.com/ClinicalGraphics/keycmd

Set aside some time early on in your project just to create a small proof of concept where you actually slap on that Textual UI. That'll inform you of what's needed later on. You don't even need to merge that proof of concept, the point is just to discover what's needed.

Ask if you can meet (anyone from) your potential team and ask them directly.