skysight-inc/HackerNews huggingface dataset:
> Everyone complained, no one addressed the fact that for years the whole of python packaging was handled by like 2.5 people.

If I can make an observation - it has nothing to do with the number of maintainers. The problem is deep, cultural and occupies a difficult space where it might be a bug or a feature.

The root cause here is that the Python project, and surrounding community, have little real respect for backwards compatibility. The complexity of Python setups is driven by the need to run multiple - potentially even mutually incompatible in the case of 2.x v. 3.x - versions of Python.

All languages have packaging problems, but Python is unique in my experience in the sheer number of Python installs that I need to manage simultaneously. I still have C code that works from around the time that I learned C. I'd need another Python environment installed to say the same thing about Python.
https://github.com/RadeonOpenCompute/ROCm/issues/1617 appears to be the issue to track if you are interested in ROCm support for RDNA2.
That's weird, the console_scripts hook for python packages generates a script with the same python in the shebang that pip is executed with to install the said package.
It makes perfect sense. For a question like "which types of waste do you transport" you ideally want to differentiate between "None, I don't transport waste", "Other, I transport waste that isn't on the list", "I don't know/don't want to tell you" and "I forgot to answer this question". But it's really easy to design a form so that all of these map to not checking anything, which will probably lead you to drawing wrong conclusions when looking at results with lots of no-answers.

And in this case they did the right thing and don't allow you to both check "none" and any of the other checkboxes, preventing you from giving nonsensical answers.
Pretty much every TV documentary or larger production (e.g. Eurovision) is still 50/60Hz though.

It's only the narrative based shows that try to be "cinematic" which are at those low fps rates.

But the technology is there, it works just fine.
Apt install python-pip3

You'll get pip3 from Python 3.6.

apt install python3.8

You'll get system-level python3.

Use pip3 in 3.6 to install the latest pip3 that requires Python 3.8, and drops that package in the dist-packages folder, which is shared between system Python runtime versions.

Behold as further attempts to do something sane with APT blow up, because now you have 3.8 packages on 3.6's runtime path.

I've lost weeks to this particular brand of distro daftness. I thought that surely no one would do that
.. Alas...
The first thing unbreakable Linux did was break.
If you click on the link and read the header (not the actual article or it's title) you will see that it's posted on Julia Evans blog. That should answer your question.
In an enterprise world, you can't rely on dependencies being present on the target machine, so install a .venv/ directory in your application distribution containing all the libraries (populated by pip) and a bin/venv-python wrapper script to set PYTHONPATH correctly and to call the .venv/bin/python. Then create a bin/run-app script to call bin/venv-python, with the location of your entry point module from src/python/

In summary: bin/run-app -> bin/venv-python -> .venv/bin/python -- I'm not sure how to make it simpler than this. The cost is perhaps in disk space, but I don't care about that.

Or don't do the above and deploy via docker and use pip to install to the system python in the image.
This article is exceedingly poorly written.
Well, that's not true:

- Almost all distros don't just supply one version of a package. They try to avoid it, but I can't recall one with a hard rule against it. For instance, Debian packages multiple versions of autoconf https://packages.debian.org/search?keywords=autoconf2 , the Linux kernel, etc.

- One reason that distros try not to install multiple versions of a package is that it's hard to specify which one you want. If you have, say, requests 1.0 and 2.0 installed, which one does "import requests" get you? The virtualenv approach, where "import requests" simply does not work in an un-virtualenv'd Python, avoids this problem entirely. Each application can independently build-depend on python-requests-1 or python-requests-2, and each user can create their own virtualenv and pip install /usr/share/wheels/requests-1.whl or requests-2.whl as they prefer.

- Even if you do not have different versions of the same library, it may well be the case that you have two different libraries with the same importable name. As a great example, see CJ Wright's talk from PackagingCon last week "Will the Real Slugify Please Stand Up" https://pretalx.com/packagingcon-2021/talk/P3983F/ (I expect they'll post videos online soon). tl;dr there are three packages you can get via "import slugify", and they expose different APIs.

- The possibility you haven't accounted for is "The library ecosystem is like that because things are fast-moving, because people have actual problems they want to solve, and upgrading dependencies and sorting out conflicts is work." It would be great for that work to be done, but we go back to the problem I mentioned at the top - limited volunteer time. In the absence of time to engineer things perfectly, your options are to ship something that's engineered imperfectly or decide not to ship it. We went through the dark ages of "We'll ship the next Debian release when all the bugs are solved" over a decade ago, and it turns out that this doesn't actually help users in any way.
Yup, this kinda works.

It doesn't address the greater issue tho: that it's getting harder and harder for distributions to package things right, and provider packages for their users (evidenced by the fact that you need a second package manager just for python stuff).
You're not getting off this easy.

This is what you said:

> In 1994, "the west" will supply Chechen insurgents and help them with press campaigns and supply via proxy.

Where's the sources that "the west" supplied the Chechen insurgents and helped them?

And please share an English version of wikipedia, not a yandex translated version of a wikipedia page in Russian that has edits which have not even been verified. (which should have an equivalent in English anyway but I could not find it)

What I would expect is similar to the CIA involvement in Afghanistan when Russia invaded which is widely sourced and documented and a quick google search away. If there was such involvement as you say, it would have sources already. (that being 30 years ago)
Fun fact, in the excellent book ‘Daily Rituals: How Artists Work’, the word Coffee appears 78 times. That’s almost every other page.
That's too bad. It's starting to feel like 3.1 is never going to gain adoption unless we get entirely new tools built for it.
Kinda diffrent Rust its like 3 years old when it start getting popular. Python is 13+ years old when it starts getting very popular.
You cannot compare legacy to modern solution -.-
Is it fair to compare an interpreted language and its package manager to Rust and Cargo? Python packages ship their source (in most cases), depend on a locally installed interpreter (with semantics possibly changing by version).

Yes, Python packages often make poor assumptions about what setup.py can do (i.e., _anything_), and so you end up choosing between "tested, supported by the author, and old" or "untested, unsupported, but up to date".
> I always avoid pinning dependencies

This is an very quick route to a maintenance nightmare imo.

If you have totally unpinned dependencies, and you come back to a project after a year untouched, or 5 years, and it no longer works - which dependency update broke it?

I don't agree that using an outdated package is necessarily a problem at all. Some versions are done! You don't need the latest version of every possible package. You don't necessarily need to update _ever_ (which is why this differs from CI). These updates are often entirely unnecessary churn.

There absolutely are vulnerabilities in some old versions, and those updates are necessary (but tooling & notifications to easily handle this have dramatically improved in recent years, especially on GitHub). There will also be vulnerabilities in new packages though, which may be unknown, and will often not exist in older much simpler versions.

Using a well-tested version of a dependency that does exactly what you need is not less secure than chasing the latest version at all times without a specific reason.

I've found manually updating packages on the rare occasions where relevant vulnerabilities arise, and using existing working versions without changes the rest of the time has been perfectly effective over many years now, and avoid the shifting sands of external dependencies wherever possible means that a project that worked 5 years ago still works _exactly_ the same today.

I rather see more software go in this direction, valuing reproducibility & known correctness (i.e. with isolated pinned dependencies, in some form) over 'always be latest' dependency updates and the complex & hard to reproduce bugs that those shifting dependency interactions can create.
Record Ecommerce Demand Coupled with Shortages
Cargo is a good example of a survivorship bias of sorts. It's so deeply integrated into rust that if you can't stomach it you just leave the ecosystem and everyone that remains likes it ;)
FYI, there is a name clash with Caffeine, a Mac OS menu bar app that keeps the screen awake: https://intelliscapesolutions.com/apps/caffeine . But I guess this is expected with a name like this, and the scopes of the projects are clearly different, so this should be relatively harmless.
End of the cable isn't the best place, you will still need a connector capable to handle gazillion amps and also solid hunks of copper inside car to connect it to battery. Better to integrate it directly into battery packs.
Love mgmt's idea. Thanks for all the hard work of getting it started, good to see people starting to join you in development.
Are you thinking of central sensitization?

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2750819/
Yes, python packaging is a mess.

And agreed, there are two separate use cases: development and using the software.

But, are distros creating too much work for themselves by trying to package every itty-bitty python library (and for that matter, every npm library)? Are distros doing anything more than scanning CVE databases with the library versions, or are they _actually_ auditing the versions they choose? (Not that there's much choice, since python also has a shitty story when it comes to backwards compatibility; if you're going with 3.10, there's possibly only one version of a given library that will work.)

Java has a commonly used "fat jar" approach which rolls up all dependencies into a single file. It's excellent. In the python world, this doesn't exist, because virtualenvs aren't portable. If that can be fixed (perhaps a specific section in requirements.txt that captures anything that needs to compile C for the platform) then a distributable virtualenv would become possible. Distros would then scan the application for vulnerabilities (via requirement.txt's manifest), build the distributable-virtualenv, and ship _that_. Python library maintainers don't have to do anything different (except, of course, use the standard way to declare dependencies).
I think there is an increasing trend for developers to get confused between their tools and their output.

These are your tools:

* pip
* pip-tools
* pipenv
* poetry
* virtualenv
* venv
* setuptools
* pyenv
* requirements.txt
* etc.

These are your outputs:

* wheel (binary),
* tarball (source).

The tools in use are completely irrelevant and only add noise to the discussions around packaging. So what actually is the problem here? Are projects delivering broken outputs (ie. bad packages)? Are they not delivering outputs at all? Those are real problems but pointing at the number of tools that exist is not helping.
Years ago I noticed any webpage could just use an <img> tag to include an image hosted in my LAN. For example, adding such a tag to any website to include a link to the usual gateway ip addresses (192.168.0.1 and so on) will trigger an http authentication dialog for many users.

It's the kind of thing that I thought would be impossible because it seems like such a boundary crossing. Glad they are eventually fixing this...
yeah, all these pundits have no idea about anything regarding aliens...what do they really know? It's all pure speculation, mostly nonsense..
> If your distro dumps all the installed files into `/usr/lib/python3`

Oh dear... What kind of monster does this?
You can just give a random guess on the timelines and save the developers time.
Well, switch to LFP is in progress right now to reduce battery fires.
OpenStack uses pbr which they created and which is pretty cool. I use setupmeta for the same purpose but could have used pbr.

https://github.com/openstack/pbr
https://github.com/codrsquad/setupmeta
You can have a fixed scope with a flexible timeline, or a flexible scope with a fixed timeline. If you try to have both, you'll incur an additional cost, which most companies avoid. It's a well known law of project management and software development.
> Your best bet is to try and remove as much config as possible first.

Which config?

> Webpack allows you to paint yourself so far into a corner

https://news.ycombinator.com/item?id=29239108
SF spreads a lot of FUD saying that DB can’t perform, and it was true. DB then went out and hired a lot of engineering talent with a diverse background and has been investing a lot of money in being a best in class SQL offering, so what do you do? You do something to get people’s attention. They’re saying, “hey, we have great performance too, you should also look at us for your SQL workloads.”
I'm a CS student as well, curious what course taught you about ECC? Would be interested in such a course as well, the only course I can imagine teaching this is an information theory course (which my university doesn't offer).
No, it’s Protestantism and the pernicious concept of grace as opposed to good works in Judaism, Catholic/Orthodox Christianity or Islam. If you are poor, you must be cursed by God and therefore deserve everything that happens to you. What’s more, the elect who have grace are entitled to make your life even worse for their benefit.
and thus will reinvent the wheel - instead of simply including executable javascript into the pdf

All things become browsers given enough time..
"Thou shalt not mess with the system Python"
The statistics you cite are related, but doesn't refute the point that men who ask for full custody win more often. I don't know if that's true or not, but it can be true and also only 1/6 custodial parents being fathers can be true. It simply requires that significantly fewer men ask for full custody.
> I have no idea how the dev got their setup working

Tip: in such situations I start looking at the CI scripts in their repositories. Not ideal but gets me through!
Maven was launched 9 years after Java got popular. Everybody was using Ant, everybody decided Ant sucked and moved to the new solution. While Gradle is the new kid on the block, it keeps the infrastructure of dependency management and is thus compatible with Maven to that extent. It can be done.
> UK's forests are already up to "medieval" levels

That is not a very high standard; as far as I recall, Britain has been a cultured landscape at the very least since the Iron Age. (Related to that is the fact that medieval population of Britain has also been roughly at Iron Age levels, or vice versa. There were apparently around four million people in Iron Age Britain.)
How is Pip any different than Cpanm, NPM, Gem, Luarocks, Nimble, Go's thing, Cargo, whatever JVM people use, whatever Haskell people use, etc. in that regard?

Distros have a hard job, but at the same time programming language tooling devs have more "customers" than just distro maintainers.
> They might reconsider marriage as an institution altogether.

While I dont disagree with your statements, the statistics don't lie.

Men in marriage live longer and healthier lives on average to men in long-term relationships and to single men.
Distros, please stop screwing over Python packaging. It is incredible that Debian/Ubuntu pick Python apart and put modules into different packages. They even create a fake venv command that tells you to please install python-venv.

What they should just do is offer a bunch of packages like python3.7, python3.8 that install the official python package wholesale into /usr/python or someplace and then symlink one of them to `python`.

If I would get to redesign package management (both for Linux distros and for languages), I would have one package manager that installs everything into a global package cache, and then pick the correct version of libraries at run time (for Python: at import time). Get rid of the requirement that there is only one stable (minor) version of a package in the distribution at one time. This has become unworkable. Instead, make it easy to get bleeding edge versions into the repositories. They can be installed side by side and only picked up by the things that actually use them.
So there's a few types of projects you can write in Python:

1. Server applications that run in a dedicated environment.

2. Tools you write and run just on your machine (or some virtualenv, whatever).

3. Redistributable cli or desktop applications which end users will install and use.

For the first two types, you should never have any issues with Python and its dependency situation. You pin everything, and that's it.

For the third kind tho, it's complete pain. Different distros ship different Python versions, so you need to support all of them. You also have to consider that dependencies can't be an EXACT version, you have to support a range of them, and a variety of combinations.

And then, one dependency has a version that works in Python3.6, and another for 3.9. But they had an API change, so which one do you use? It'll break for half your users either way. Of maybe just put some `if version <= 3.6` all over the place, like we did during the py2->py3 transition?
It does matter in a CI environment. Using a different build procedure there is not optimal.
Then I go with something like docker-compose
> I don't understand what value distribution is providing by repackaging python libs...

I want to easily and safely use some app my distribution ships. I want to receive security updates automatically for all such apps. I don't care what language it's written in or what its dependencies are.

These app packages provided by the distribution have dependencies that are also packaged by the distribution so that dependency resolution works.

Since the point of a distribution is that it can run apps, the value is that a distribution works at all.
If you don't enable encryption, many browsers reduce functionality available to you.
That's exactly what I was thinking of when I said we sometimes give estimates depending on who it gets assigned to. "It'll take a day if X does it, but probably three if another SE does it".
A suggestion:

1) If your distro requires Python, don't put it on the path. Refer to it another way if you need it, e.g. have a distroname-system-python package you upgrade at your own cadence.

2) That's it. Then developers can install Python how they like, and it's (probably) all fine.
I find it really good. It's super stable, I have it running 24/7 for a month at a time and FreeBSD has some really nice things that Linux is only now catching up on. Like ZFS on root (snapshotting your desktop is so cool). It's never crashed on me. Unlike my Mac.

Hardware issues are present yes. Your hardware may vary of course. In my case I had to turn off bluetooth on my NUC (NUC5i5RYK). Because it hangs on boot with some cryptic messages. I probably could have troubleshooted it more but because all my peripherals are wired I didn't really care :)

Also, I don't think sleep works (I don't care, I want it to be ready for me all the time) and I didn't even try WiFi (I have wired ethernet)

In fact the sleep thing is one thing I hated about my Mac Mini. Apple always forces some kind of sleep.. Every morning when I logged in my apps would have this state of "oh wait, just catching up" despite me having switched off all the sleep states with "pmset" and in the GUI, and using an app ("Jiggler") to fake mouse inputs every few minutes. Yet the apps still go to some kind of sleep somehow. Which meant it would take a couple of minutes to be responsive again. I looked it up and this is some "app nap" thing or something. Cool but let me turn it off. My desktop takes 5-10W idle so this is really not something I care about. And during the night I schedule stuff like backups.

Another thing where FreeBSD shines are the jails. I've used them for 15 years and you can even jail GUI apps now. Linux has snaps etc but they're really slow to start up and clutter your mounttab. I prefer this.

But anyway yeah it's really stable. Wayland is not working at the moment but it's being worked on. The developers are extremely quick and responsive at #freebsd-desktop on libera. When a new KDE version comes out they usually have it ready in a day or so. Which is pretty amazing compared to most Linux distros.

I don't use any linux emulation right now. I don't need it. Any apps that were not packaged for FreeBSD I was able to compile natively or use an alternative.

What I also like about FreeBSD is that it's just one OS instead of one kernel and hundreds of distros (basically OSes) doing things around it in different ways. There's usually one good and well documented way to do things, but not by hiding powerful configurability from you like most 'modern' OSes do. If you're looking for something the handbook usually has the answer (though it should be kept up to date more...)

The ports collection is also super. If you want a package but with different compile options than it comes standard you can just do so.
Bird Eats Bug
Varna is decided by karma, not birth. Dalits can and do become brahmins by following diets, rituals and become temple priests. Brahmins also have become kshatriyas by picking up weapons of war.

[1] https://indianexpress.com/article/india/kerala-dalit-priests...

[2] https://en.wikipedia.org/wiki/Brahmakshatriya
I drove off with a 30kW charger cable still attached and charging. Ironically during developement of functionality to prevent you from driving off with the cable attached.

The connector ripped out at the buss and ground faulted. Nothing spectacular happened.
Much more important is the new Child Tax Credit ($3000 per year).
Are you suggesting regulating IOT devices for better security? Who the heck could you trust to do that? The FCC? The Chinese government? Consumer rights in the USA is barely a thing, and there is no competent bureaucracy for this sort of auditing. Creating some standards body and coming up with evolving criteria and hoping manufacturers will buy in seems like a multi year, if not multiple decade, process...

In the meantime Google can single handedly monkey patch this situation within a few months and force manufacturers to catch up with the next product cycle. While a less ideal route, this seems far likelier to produce actual results within our lifetimes.
Freedman's Savings Bank
Which is why I'm starting to feel like Python is the new Java.
there's https://github.com/spotify/dh-virtualenv