me: “I know Python! I've been using it on and off for like 15 years!”

also me: <still has no real idea what `setup.py` does>

(not looking for someone to explain it to me thanks)

@b0rk it's ok, you can skip that and go straight to pyproject.toml anyway. :)

@b0rk show me someone who's used a language for 15 years and _doesn't_ have any random gap in their knowledge for a part they've never happened to run across, and I'll show you someone who's either straight-up bluffing, or doing a just-in-time web-search every time they're asked a question they don't know the answer to :-)

@simontatham yea this is why I post this kind of thing, I want to show it's normal to not know stuff :)

@simontatham @b0rk

A true expert is someone who knows *what* to search for.

There's plenty of other more pleasant things one can stuff your brain's limited memory with!

@b0rk

🤓 "axkshually, you're not shupposhed to use shetup anymore. "

"let me tell you about the 15 tools we have invented to simplify things."

🤣

Packaging is weirdly simple and weirdly complicated for how simple it is, don't worry about it.

@bmaxv this is a common misconception, setup.py is very much not deprecated.

*Running* setup.py directly as a program, on the other hand, is.

@b0rk I think you can just skip that and move to not having a real idea what setup.cfg, err, pyproject.toml does.

@SnoopJ Ok.

Here is the official building, packaging, distribution project.

Notice how it doesn't contain setup.py?

https://github.com/pypa/sampleproject

All that's missing for the deprecation is the announcement.

@bmaxv right, if setuptools announces that it is deprecated, then it will become deprecated.

I anticipate that to happen never.

It is possible that in the future `pip` might drop support for legacy projects that predate PEP 517, but this hasn't happened yet.

@bmaxv in short:

Out of favor? Certainly.

Deprecated? Absolutely not.

@simontatham @b0rk I’ve been using #git for over a decade and yesterday I learned about `git worktree` which is exactly what I’ve needed every day for the last four years.

@b0rk I had this very experience yesterday as I was trying to wrap my head around pipenv, pipx, flit, hatch, pdm, build, project.toml, poetry, and about a half dozen PEPs.

@b0rk

@SnoopJ @bmaxv until ~2 years ago (last substantial python I did), I still occasionally saw people start *new* projects with distutils. And even more frequently, importing six for new python3 stuff.

Nothing ever dies in the python ecosystem.

@simontatham @b0rk Often even a very experienced and knowledgeable programmer can have big gaps in their knowledge - but they know where they are. "Oh yes, IDK anything about <feature>. I do remember that it's full of beartraps, so I avoid it and recommend that others do so too."

@Diziet, thanks, that’s exactly how I’m going to answer questions about C++ from now on.

@simontatham @b0rk

@Diziet @simontatham @b0rk On a slightly related note, I once half-joked to a colleague+friend who is an electrical engineer working as a (very experienced and knowledgeable) software developer, that I’d be wary of (non-software) engineers programming, and he answered in earnest that he was well aware that his programming knowledge had limits and that he took care to steer clear of them. Chapeau!

@DrHyde @b0rk also, I think git is _particularly_ prone to this, because it's so broad. There are a zillion outlying git features and subcommands, and each one is useful for _something_, but a lot of them are pretty much independent of each other – you don't have to learn lots of them at once, or learn one in order to use another.

So the only way you'd ever learn all of them in advance would be by reading the entire manual … and having a _really_ good memory.

@simontatham @DrHyde @b0rk There are also quite a few commands that need to be run infrequently enough that one doesn't automatically build the muscle memory for them, but are common and time-saving enough that learning them is still useful. I have a whole file full of useful utility features to remember that I should publish at some point. (I think Neovim appears the most in that list because editors are another type of tool that lend themselves to what you're describing.)

@breakerandahalf @simontatham @b0rk one of these years I might migrate from #vim to #neovim. But not this year.

@DrHyde @simontatham @b0rk Well. that list just includes brief cheatsheets on marks, tabpages, and folding with markers, all of which are helpful but are things I don't use enough to have an innate knowledge of (yet). I think everything in that list, however, also applies to Vim because so much of the behavior of the two editors is the same.

In my experience, the differences between the two are kind of a wash unless you really want something that only Neovim has. (Although being able to write configs in Lua is nice.)

@breakerandahalf @simontatham @b0rk yeah, every time I have to even read #vimscript, let alone write it, I get a little bit ragey.