fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

8.8K
active users

#setuptools

0 posts0 participants0 posts today
mgorny-nyan (on) :autism:🙀🚂🐧<p>Nowości w świecie Pythona: <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> teraz zawiera zagnieżdżone zależności z licencją LGPL. Nie żeby mi to robiło różnicę (aczkolwiek są ludzie i firmy, dla których to stanowi problem) — ale te zależności nie są&nbsp;nawet używane! Na przykład `autocommand` to zależność kilku skryptów w `jaraco.text`, które nie są używane przez setuptools.</p><p>A czekaj, jednak mi to robi różnicę, bo muszę poprawić LICENSE w dev-python/ensurepip-setuptools.</p><p><a href="https://github.com/pypa/setuptools/issues/5045" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/setuptools/iss</span><span class="invisible">ues/5045</span></a><br><a href="https://github.com/pypa/setuptools/issues/5049" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/setuptools/iss</span><span class="invisible">ues/5049</span></a></p><p><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>New in <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a> world: <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> now vendors deep dependencies with LGPL license. Not that I do mind (but some people and companies do!) — but these dependencies aren't even used! I mean, `autocommand` is just a dependency of some scripts in `jaraco.text` that aren't used by setuptools.</p><p>Oh, wait, I actually do care, because I need to fix LICENSE in dev-python/ensurepip-setuptools.</p><p><a href="https://github.com/pypa/setuptools/issues/5045" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/setuptools/iss</span><span class="invisible">ues/5045</span></a><br><a href="https://github.com/pypa/setuptools/issues/5049" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/setuptools/iss</span><span class="invisible">ues/5049</span></a></p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>Ciekawostki o Pythonowym "limited API" i "stable ABI".</p><p>1. <a href="https://pol.social/tags/CPython" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CPython</span></a> ma "limited API". Jak się tego używa, to kompilowane rozszerzenia są zgodne ze wskazaną wersją i wersjami nowszymi. Takie rozszerzenia dostają sufiks `.abi3.so` (albo podobny) zamiast np. `.cpython-313-x86_64-linux-gnu.so`.</p><p>2. Wsparcie podzielone jest między CPythona i systemy budowania <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PEP517</span></a>. Np. w <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> podaje się `py_limited_api=`, i wówczas przy budowaniu dodawane są odpowiednie flagi kompilatora i podmieniany jest sufiks rozszerzeń. <a href="https://pol.social/tags/Meson" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Meson</span></a> ma coś podobnego.</p><p>3. Ale wersja "freethreading" aktualnie nie obsługuje "stable ABI", więc przy budowaniu z "limited API" dostaje się błąd kompilacji. Podobnie, setuptools rzuca błąd jeżeli z interpreterem freethreading podamy `py_limited_api`, a Meson po prostu pozwala się wysypać kompilacji. Tak więc autorzy paczek muszą sami sprawdzać, czy użyto kompilatora "freethreading", i wyłączyć wówczas "limited API".</p><p>4. Bliżej nieokreślona przyszła wersja CPythona naprawi to wsparcie. Nie przyglądałem się tematowi dokładnie, ale podejrzewam, że będzie to tylko możliwe,&nbsp;jeżeli będziemy budować rozszerzenia dla tej bądź nowszej wersji. Więc ludzie pewnie będą musieli budować dwie wersje — tę dla starszych CPythonów, i dla nowszych + "freethreading". No i oczywiście będzie trzeba odpowiednio zaktualizować warunkowe załączanie "limited API".</p><p>5. No i jest jeszcze <a href="https://pol.social/tags/PyPy" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PyPy</span></a>. PyPy nie ma "stable ABI", ale pozwala budować rozszerzenia z "limited API". Setuptools i Meson po prostu wykrywają, że interpreter nie obsługuje sufiksu `.abi3.so`, i buduje rozszerzenia z normalnym sufiksem.</p><p><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>Some fun facts about <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a> limited API / stable ABI.</p><p>1. <a href="https://social.treehouse.systems/tags/CPython" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CPython</span></a> supports "limited API". When you use it, you get extensions that are compatible with the specified CPython version and versions newer than that. To indicate this compatibility, such extensions use `.abi3.so` suffix (or equivalent) rather than the usual `.cpython-313-x86_64-linux-gnu.so` or alike.</p><p>2. The actual support is split between CPython itself and <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PEP517</span></a> build systems. For example, if you use <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> and specify `py_limited_api=` argument to the extension, setuptools will pass appropriate C compiler flags and swap extension suffix. There's a similar support in <a href="https://social.treehouse.systems/tags/meson" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>meson</span></a>, and probably other build systems.</p><p>3. Except that CPython freethreading builds don't support stable ABI right now, so building with "limited API" triggers an explicit error from the headers. Setuptools have opted for building explicit about this: it emits an error if you try to use `py_limited_api` on a freethreading interpreter. Meson currently just gives the compile error. This implies that package authors need to actively special-case freethreading builds and enable "limited API" conditionally.</p><p>4. A some future versions of CPython will support "limited API" in freethreading builds. I haven't been following the discussions closely, but I suspect that it will only be possible when you target that version or newer. So I guess people will need to be building two stable ABI wheels for a time — one targeting older Python versions, and one targeting newer versions plus freethreading. On top of that, all these projects will need to update their "no 'limited API' on freethreading" conditions.</p><p>5. And then there's <a href="https://social.treehouse.systems/tags/PyPy" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PyPy</span></a>. PyPy does not feature a stable ABI, but it allows you to build extensions using "limited API". So setuptools and meson just detect that there is no `.abi3.so` on PyPy, and use regular suffix for the extensions built with "limited API".</p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>Dni bez przypadkowego projektu na <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> migrującego na `pyproject.toml`, usuwającego plik `MANIFEST.in` i wskutek tego psującego archiwum ze źródłami: [0].</p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>Days since a random <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> project migrated to `pyproject.toml`, removed `MANIFEST.in` and broke source distribution in the process: [0].</p><p><a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Gentoo</span></a></p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>Nieudany poranek z nowymi wersjami paczek Pythona dla <a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Gentoo</span></a>:</p><p>1. Projekt, który zwlekał z wydaniem nowej wersji z poprawkami bezpieczeństwa 4 lata, w końcu wydał nową wersję. Oczywiście, jak się robi jedno wydanie na 7 lat, to definitywnie trzeba w tym czasie zmienić system budowania na zepsutą hybrydę <a href="https://pol.social/tags/PythonPoetry" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PythonPoetry</span></a> + <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a>.</p><p>2. Inny projekt wydał nową&nbsp;wersję z popsutymi testami. Na głównej gałęzi działają — widać nikomu nie zależało, żeby przetestować gałąź z wydaniem.</p><p>3. Właśnie odkryłem, że kilka paczek na nowo zaczęło używać przestrzeni nazw pkg_resources — a byłem przekonany, że pozbyliśmy się tego gówna lata temu! No i oczywiście, że <a href="https://pol.social/tags/Google" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Google</span></a>. A że teraz pkg_resources jest oficjalnie przestarzałe, rzuca ostrzeżeniami, które psują testy w innych paczkach.</p><p>A z rzeczy pozytywnych: w redis-py sypie mi się test_lolwut.</p><p><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>A bad <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a> bump morning in <a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Gentoo</span></a>:</p><p>1. A project that couldn't be bothered to make a release with a security fix for 4 years finally made a release. Of course, if you make one release in 7 years, it is definitely a good idea to replace your build system with a broken <a href="https://social.treehouse.systems/tags/PythonPoetry" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PythonPoetry</span></a> + <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> hybrid.</p><p>2. Another project made a release with a bunch of test failures — that were fixed in "master" branch already at the time, but I guess nobody bothered testing the release branch.</p><p>3. Just discovered that a bunch of projects are using pkg_resources namespaces again — and we were supposed to have gotten rid of them years ago! Of course it's <a href="https://social.treehouse.systems/tags/Google" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Google</span></a>. And on top of that, since pkg_resources are now throwing deprecation warnings, they are indirectly breaking random other test suites.</p><p>On the positive side, test_lolwut is failing for me in redis-py.</p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>Paczka Pythona, której nie idzie zainstalować na Pythonie 3.14, bo autor koniecznie musiał zaimplementować przetwarzanie AST na ponad 200 linii w `setup.py`? Dlaczego nie.</p><p><a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Gentoo</span></a> <a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a> <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>A <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a> package that can't be installed on Python 3.14, because the author had to implement a 200+ line custom AST parser in `setup.py`? Yeah, why not.</p><p><a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Gentoo</span></a> <a href="https://social.treehouse.systems/tags/packaging" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>packaging</span></a> <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a></p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>co jest gorsze niż <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a>? Paczka, która przechodzi na <a href="https://pol.social/tags/Hatchling" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Hatchling</span></a>, ale wewnętrznie woła w paskudny sposób setuptools, żeby zbudować rozszerzenie w C — i w ten sposób ignoruje budowanie poza katalogiem źródłowym.</p><p><a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Gentoo</span></a> <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PEP517</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>What's worse than <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a>? A package switching over to <a href="https://social.treehouse.systems/tags/Hatchling" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Hatchling</span></a>, then internally calling setuptools in an awful way to build a C extension, completely bypassing out-of-tree builds.</p><p><a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Gentoo</span></a> <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PEP517</span></a></p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>Uwaga: <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> ogłosiło, że `setup.py install` wyleci 2025-10-31.</p><p><a href="https://setuptools.pypa.io/en/latest/history.html#v80-1-0" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">setuptools.pypa.io/en/latest/h</span><span class="invisible">istory.html#v80-1-0</span></a></p><p><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a> <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PEP517</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>PSA: <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> added a deadline for `setup.py install` removal: 2025-10-31.</p><p><a href="https://setuptools.pypa.io/en/latest/history.html#v80-1-0" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">setuptools.pypa.io/en/latest/h</span><span class="invisible">istory.html#v80-1-0</span></a></p><p><a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a> <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PEP517</span></a> <a href="https://social.treehouse.systems/tags/packaging" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>packaging</span></a></p>
mgorny-nyan (on) :autism:🙀🚂🐧<p><a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> jest super: jeżeli macie gdzieś w źródłach dowiązanie symboliczne do katalogu, to setuptools przypadkowo zdecyduje, by do dystrybucji źródłowej albo dodać oryginalny katalog, albo przenieść&nbsp;go w miejsce dowiązania, ignorując oryginalną lokalizację.</p><p>Więc jeżeli macie:</p><p>a/a<br>a/b<br>a/c<br>b -&gt; a</p><p>to przypadkowo dostaniecie albo:</p><p>a/a a/b a/c (bez "b")</p><p>albo:</p><p>b/a b/b b/c (bez "a")</p><p><a href="https://github.com/pypa/setuptools/issues/4937" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/setuptools/iss</span><span class="invisible">ues/4937</span></a></p><p><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>So <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> fun: if your source tree contains a symbolic link to a directory, setuptools may randomly either include the original directory in the source distribution, or move it where the symlink was, disregarding the original location.</p><p>So if you have:</p><p>a/a<br>a/b<br>a/c<br>b -&gt; a</p><p>you'll randomly end up with either:</p><p>a/a a/b a/c (and no "b")</p><p>or:</p><p>b/a b/b b/c (and no "a")</p><p><a href="https://github.com/pypa/setuptools/issues/4937" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/setuptools/iss</span><span class="invisible">ues/4937</span></a></p><p><a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a> <a href="https://social.treehouse.systems/tags/packaging" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>packaging</span></a></p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>Skoro już ugaszono te największe pożary, porozmawiajmy o innych fajnych rzeczach, które dzieją się&nbsp;z <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a>.</p><p>Na ten przykład, setuptools niedawno zaimplementowało PEP 639 (nowe metadane, dotyczące licencji). Przy okazji oznaczyli swoje poprzednie pole `license-field` jako przestarzałe, dając ludziom czas do 2026-02-18 na podmianę. Ostrzeżenie podpowiada też, że nowe pole wymaga setputools w wersji 77, którą&nbsp;wydano… tydzień temu.</p><p>No więc setuptools praktycznie mówi nam, że mamy do wyboru: albo używać&nbsp;starego rozwiązania, które oznacza, że wszystkie używające go wersje paczki przestaną się budować w lutym przyszłego roku, albo nowego rozwiązania, które wymagać będzie wersji setuptools sprzed tygodnia (i pozbawi was możliwości wsparcia starszych wersji Pythona, które najwyraźniej obchodzą jeszcze parę projektów).</p><p>No i rzecz jasna społeczność pythonowa podpowie: przypnij konkretną wersję zależności. Możecie sobie wyobrazić, jaka to będzie wielka frajda, kiedy jedne projekty zaczną arbitralnie przypinać wersję&nbsp;setuptools (np. do &lt;77), żeby pozbyć&nbsp;się&nbsp;ostrzeżeń, a inne będą wymagać &gt;=77 ze względu na nową konfigurację.</p><p>W takim razie… może mają państwo ochotę porozmawiać o systemie budowania flit? Albo o hatchling?</p><p>PS. A najśmieszniejsze w tym wszystkim to, że ostrzeżenie odnosi się do instrukcji, której jeszcze nawet nie zaktualizowano i która nadal twierdzi, że setuptools nie obsługują PEP 639.</p><p><a href="https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/config/_apply_pyprojecttoml.py#L100-L106" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/setuptools/blo</span><span class="invisible">b/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/config/_apply_pyprojecttoml.py#L100-L106</span></a><br><a href="https://web.archive.org/web/20250324035753/https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-files" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">web.archive.org/web/2025032403</span><span class="invisible">5753/https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-files</span></a></p><p><a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PEP517</span></a> <a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>So, now that the urgent fires have been put out for the time being, let's talk what other fun stuff <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> are doing these days.</p><p>For example, they have implemented PEP 639 recently (new license metadata). While doing that, they immediately deprecated their previous `license-field` field, giving people until 2026-02-18 to update their projects. The deprecation warnings also gives a helpful hint that you need setuptools 77 for the new field, which was released… a week ago.</p><p>So yeah, setuptools pretty much tells you that you need to choose between the old solution that means that all the versions of your package using it will stop building next February, or the new solution which means that your package will now require a week-old setuptools release (and effectively kill support for EOL Python versions, for which some projects apparently still care).</p><p>And of course the <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a> community will tell you to solve the problem by pinning dependencies. And guess what happens when people put arbitrary pins (say, &lt;77) to silence this deprecation warning, and other people have &gt;=77 dependency, because they use the new variant.</p><p>So… would you like to talk about flit, perhaps? Or hatchling?</p><p>PS. The best joke is that they're pointing at a packaging guide that hasn't even been updated yet and still states that setuptools do not implement PEP 639.</p><p><a href="https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/config/_apply_pyprojecttoml.py#L100-L106" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/setuptools/blo</span><span class="invisible">b/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/config/_apply_pyprojecttoml.py#L100-L106</span></a><br><a href="https://web.archive.org/web/20250324035753/https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-files" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">web.archive.org/web/2025032403</span><span class="invisible">5753/https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-files</span></a></p><p><a href="https://social.treehouse.systems/tags/packaging" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>packaging</span></a> <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PEP517</span></a></p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>Na kanwie mema z dominem:</p><p>1. <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> zaczyna normalizować nazwy plików archiw binarych, w zgodzie z PEP 491.<br>…<br>n. <a href="https://pol.social/tags/PyCXX" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PyCXX</span></a> nagle zaczyna instalować nagłówki w `/usr/include/python*/cxx` zamiast `CXX` (wielkimi literami).</p><p>Co ciekawe, problem dotyka zarówno paczek <a href="https://pol.social/tags/pip" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>pip</span></a> i <a href="https://pol.social/tags/installer" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>installer</span></a>. Krótko mówiąc, ścieżka instalacji nagłówków używa "nazwy dystrybucji", i wygląda na to, że w obydwu przypadkach nazwa ta pobierana jest z nazwy pliku. Nie wiem, czy to błąd, ale myślę, że zgłoszę, na wszelki wypadek. W installerze nawet jest notatka, wskazująca, że autor nie był pewny, czy używać oryginalnej, czy znormalizowanej nazwy.</p><p><a href="https://discuss.python.org/t/installing-headers-from-wheel-should-the-directory-be-normalized-or-not/85990" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">discuss.python.org/t/installin</span><span class="invisible">g-headers-from-wheel-should-the-directory-be-normalized-or-not/85990</span></a></p><p><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>Domino meme:</p><p>1. <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setuptools</span></a> starting to finally normalize wheel filenames per PEP 491.<br>…<br>n. <a href="https://social.treehouse.systems/tags/PyCXX" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PyCXX</span></a> suddenly installing header files into `/usr/include/python*/cxx` instead of uppercase `CXX`.</p><p>Funny enough, it affects both <a href="https://social.treehouse.systems/tags/pip" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>pip</span></a> and <a href="https://social.treehouse.systems/tags/installer" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>installer</span></a>. Long story short, the include install path uses "distribution name", and in both cases the distribution name is apparently taken from the filename. Not sure if this is a bug or a feature, but I guess i'll file bugs. Installer even has a TODO item to determine whether they should be using original or normalized name.</p><p><a href="https://discuss.python.org/t/installing-headers-from-wheel-should-the-directory-be-normalized-or-not/85990" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">discuss.python.org/t/installin</span><span class="invisible">g-headers-from-wheel-should-the-directory-be-normalized-or-not/85990</span></a></p><p><a href="https://social.treehouse.systems/tags/packaging" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>packaging</span></a> <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Python</span></a></p>