mas.to is one of the many independent Mastodon servers you can use to participate in the fediverse.
Hello! mas.to is a fast, up-to-date and fun Mastodon server.

Administered by:

Server stats:

12K
active users

#hatchling

0 posts0 participants0 posts today
Nom__XD, 飲ん,诺穆 (They/Them)🐈‍⬛<p>Music for today &lt;&lt;<a href="https://www.youtube.com/watch?v=JMyCargFq_0" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">youtube.com/watch?v=JMyCargFq_0</span><span class="invisible"></span></a> &gt;&gt; <a href="https://mastodon.social/tags/%EC%9B%90%EC%96%B4%EC%8A%A4" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>원어스</span></a> <a href="https://mastodon.social/tags/%EC%84%9C%ED%98%B8" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>서호</span></a> <a href="https://mastodon.social/tags/%ED%95%B4%EC%B8%A8%EB%A7%81" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>해츨링</span></a> <a href="https://mastodon.social/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> <a href="https://mastodon.social/tags/MV" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>MV</span></a> <a href="https://mastodon.social/tags/%E6%96%B0%E6%9B%B2%E5%85%AC%E9%96%8B" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>新曲公開</span></a> <a href="https://mastodon.social/tags/%E3%82%AA%E3%83%AA%E3%82%B8%E3%83%8A%E3%83%AB%E6%9B%B2" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>オリジナル曲</span></a> <a href="https://mastodon.social/tags/newmusic" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>newmusic</span></a> <a href="https://mastodon.social/tags/newrelease2025" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>newrelease2025</span></a> <a href="https://mastodon.social/tags/Music" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Music</span></a>🐾</p>
Arapalla<p>Willy Wagtail part 2.</p><p>This is the second hatching for this pair of wagtails this season.</p><p>Mum and dad are always busy chasing everything away.</p><p><a href="https://mastodon.social/tags/WillyWagtail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>WillyWagtail</span></a> <a href="https://mastodon.social/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> <a href="https://mastodon.social/tags/BabyBird" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>BabyBird</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>I suppose I could use my experience to give some <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a> build system recommendations.</p><p>For pure <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a> packages:</p><p>1. <a href="https://social.treehouse.systems/tags/flit_core" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>flit_core</span></a> (<a href="https://pypi.org/project/flit-core/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/flit-core/</span><span class="invisible"></span></a>) — it's lightweight and simple, and has no dependencies (in modern Python versions, for older Pythons it vendors tomli).</p><p>2. <a href="https://social.treehouse.systems/tags/hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>hatchling</span></a> (<a href="https://pypi.org/project/hatchling/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/hatchling/</span><span class="invisible"></span></a>) — it's popular and quite powerful, but has many vendored dependencies and no stand-alone test suite (which makes it painful to maintain in <a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a>).</p><p>For Python packages with C extensions: <a href="https://social.treehouse.systems/tags/meson" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>meson</span></a>-python (<a href="https://pypi.org/project/meson-python/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/meson-python/</span><span class="invisible"></span></a>) — which combines the power and correctness of meson build system with good very Python integration.</p><p>For Python packages with Rust extensions: <a href="https://social.treehouse.systems/tags/maturin" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>maturin</span></a> (<a href="https://pypi.org/project/maturin/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/maturin/</span><span class="invisible"></span></a>) — which is simply a good builder for precisely that kind of packages.</p><p>Now, I strongly discourage:</p><p>A. <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>setuptools</span></a> — lots of vendored NIH dependencies (that can alternatively be unvendored for cyclic deps), lots of deprecations over time (we're still seeing tons of deprecation warnings all over the place), many unsolved bugs (e.g. parallel C extension builds are broken in a few ways), a lot of technical debt, and if all that wasn't enough, it's slow.</p><p>B. <a href="https://social.treehouse.systems/tags/poetry" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>poetry</span></a>-core — a very tricky build system with lots of pitfalls (I've reported a lot of mistakes done when migrating to it).</p><p>C. Practically any other build system — writing new backends is trivial, so everyone and their grandmother must have one. And then, they often carry a lot of NIH dependencies (if you're reinventing a build system, you may reinvent everything else), lack experience and reintroduce the same bugs. And if that wasn't enough, packaging them in distributions is a lot of work for no real benefit to anyone.</p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>W sumie mogę dać parę rekomendacji systemów budowania <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a>.</p><p>Dla paczek w samym Pythonie:</p><p>1. <a href="https://pol.social/tags/flit_core" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>flit_core</span></a> (<a href="https://pypi.org/project/flit-core/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/flit-core/</span><span class="invisible"></span></a>) — leciutki, prosty, i nie ma zależności (za wyjątkiem włączonego tomli dla starszych wersji Pythona).</p><p>2. <a href="https://pol.social/tags/hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>hatchling</span></a> (<a href="https://pypi.org/project/hatchling/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/hatchling/</span><span class="invisible"></span></a>) — popularny, duża funkcjonalność, ale ma sporo włączonych zależności, a testy są zależne od reszty projektu hatch (przez co w <a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a> się mocno z tym męczymy).</p><p>Dla paczek z rozszerzeniami w C: <a href="https://pol.social/tags/meson" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>meson</span></a>-python (<a href="https://pypi.org/project/meson-python/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/meson-python/</span><span class="invisible"></span></a>) — połączenie szerokiej funkcjonalności i poprawności mesona z dobrą integracją z Pythonem.</p><p>Dla paczek z rozserzeniami w Ruście: <a href="https://pol.social/tags/maturin" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>maturin</span></a> (<a href="https://pypi.org/project/maturin/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/maturin/</span><span class="invisible"></span></a>) — po prostu dobry system budowania dla tego typu paczek.</p><p>Stanowczo odradzam:</p><p>A. <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>setuptools</span></a> — mnóstwo włączonych do projektu zależności, które wynajdują koło na nowo (które można zastąpić zewnętrznymi, które z kolei mają cykliczną zależność od setuptools), ciągłe wycofywanie starej funkcjonalności (której wciąż używa mnóstwo paczek), wiele nierozwiązanych problemów (np. równoległe budowanie plików C jest częściowo popsute), sporo długu technicznego, a jeżeli to nie wystarcza, to do tego strasznie powolny.</p><p>B. <a href="https://pol.social/tags/poetry" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>poetry</span></a>-core — trudny do poprawnego użycia system budowania, w którym bardzo łatwo popełnić błąd (a zgłaszałem już wiele pomyłek, które ludzie robili migrując swoje projekty).</p><p>C. Praktycznie każdy inny system budowania — pisanie nowych backendów stało się banalne, więc każdy musi mieć swój. Do tego często mają mnóstwo zależności, które wynajdują koło na nowo (jak już ktoś chce wynaleźć własny system budowania, to może równie dobrze pójść&nbsp;na całość i wynaleźć&nbsp;wszystko), brak doświadczenia i tym samym powtarzają te same błędy przeszłości. A jeżeli tego nie wystarczy, to dodawanie pod nie paczek do dystrybucji to tylko kupa roboty bez żadnej realnej korzyści.</p><p><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>Some time ago two <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a> build systems introduced <a href="https://social.treehouse.systems/tags/PyPI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PyPI</span></a> trove classifier verification. At a first glance, it makes sense. After all, if you made a mistake somewhere, you'd rather know early than when you try to upload the package. The problem is, that the verification fires for people building packages locally too — including <a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a> users.</p><p>Now, this function was based on the <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a> "trove-classifiers" package. Whenever a new classifier is introduced, a new release of the package is made. When you're building a package using tools such as `build` or `pip` (isolated build), the newest version of this package is being installed from the Internet. On the other, a Gentoo user may have an old version, unless we enforce an upgrade via package dependencies. Then building packages that use newer classifiers will fail, and with a confusing message too. Confusing because: 1) contrary to the message, the classifier is valid; and 2) even if it weren't, it doesn't affect us in any way.</p><p>And so we asked for an ability to disable this. While it took some time, the <a href="https://social.treehouse.systems/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> showed understanding and eventually merged my patch. On the other hand, the <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>setuptools</span></a> maintainer… well, started a long and tedious debate that resulted in ignoring the trivial solution to the actual problem (as "unnecessary complexity"). Instead, we were given another option: we could entirely disable `pyproject.toml` validation. It's not really acceptable, for two reasons: 1) because setuptools actually rely on this validation (so removing it could result in broken package installs instead of an error, if the file is not valid), and 2) because it produces an awful warning on every package build. So we'd end up bullying Gentoo users with false warnings, and some of them would probably end up filing invalid bugs to various upstreams.</p><p>The bottom line is: don't use setuptools.</p><p><a href="https://github.com/pypa/hatch/issues/1368" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/hatch/issues/1</span><span class="invisible">368</span></a><br><a href="https://github.com/pypa/setuptools/issues/4459" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/setuptools/iss</span><span class="invisible">ues/4459</span></a></p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>Jakiś czas temu dwa systemy budowania <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a> dorobiły się funkcji weryfikacji klasyfikatorów <a href="https://pol.social/tags/PyPI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PyPI</span></a> ("trove classifiers"). Na pierwszy rzut oka, ma to sens: wszak warto poinformować autorów paczek od razu, jeżeli gdzieś popełniono błąd i paczka zostanie odrzucona. Problem stanowi jednak fakt, że ta weryfikacja dotyczy również budowania paczek lokalnie — a więc użytkowników <a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a>.</p><p>Funkcję zbudowano w oparciu o paczkę "trove-classifiers". Ilekroć nowy klasyfikator dodawany jest do PyPI, wydawana jest nowa wersja tej paczki. Jeżeli używamy narzędzi takich jak `build` czy `pip`, każdorazowo z sieci instalowana jest najnowsza wersja tej paczki. Na Gentoo natomiast, o ile nie wymusimy tego zależnościami, użytkownik może mieć przestarzałą. Jeżeli wówczas spróbuje zainstalować paczkę Pythona, która używa nowszych klasyfikatorów, otrzyma mylący błąd o błędnym klasyfikatorze. Mylący, bowiem: 1) wbrew komunikatowi, klasyfikator jest poprawny; 2) nawet gdyby nie był, to problem nas w ogóle nie dotyczy.</p><p>Dlatego też wystąpiliśmy z prośbą o możliwości wyłączenia tej funkcji. Choć zajęło to trochę czasu, opiekun paczki <a href="https://pol.social/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> wykazał zrozumienie dla naszego problemu i zaakceptował moją łatkę. Z kolei opiekun <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>setuptools</span></a>… no cóż, podjął się długiej i bezowocnej debaty, która poskutkowała zignorowaniem trywialnego rozwiązania głównego problemu ("niepotrzebna komplikacja"). Zamiast tego, zaproponowano nam rozwiązanie dosyć wątpliwe — całkowite wyłączenie weryfikacji poprawności pliku `pyproject.toml`. Rozwiązanie nieakceptowalne z dwóch powodów: 1) dlatego, że setuptools polega na tej weryfikacji (a więc przy błędach w pliku moglibyśmy dostać zepsutą instalację zamiast błędu); 2) dlatego, że przy budowaniu każdej paczki rzuca paskudnym ostrzeżeniem. W praktyce więc znęcalibyśmy się nad użytkownikami Gentoo, zarzucając ich fałszywymi ostrzeżeniami, i niektórzy z nich prawdopodobnie niepotrzebnie zgłaszaliby problem autorom właściwej paczki.</p><p>Nie używajcie setuptools.</p><p><a href="https://github.com/pypa/hatch/issues/1368" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/hatch/issues/1</span><span class="invisible">368</span></a><br><a href="https://github.com/pypa/setuptools/issues/4459" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/setuptools/iss</span><span class="invisible">ues/4459</span></a></p><p><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a></p>
Hugo van Kemenade<p><span class="h-card" translate="no"><a href="https://hachyderm.io/@ofek" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>ofek</span></a></span> Hello and welcome to Mastodon!</p><p><a href="https://mastodon.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a> people: give <span class="h-card" translate="no"><a href="https://hachyderm.io/@ofek" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>ofek</span></a></span> a follow, he's the author of the <a href="https://mastodon.social/tags/Hatch" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatch</span></a> project manager and the <a href="https://mastodon.social/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> build backend, plus cool tools like <a href="https://github.com/ofek/pypinfo" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">github.com/ofek/pypinfo</span><span class="invisible"></span></a>, and wrote <a href="https://mastodon.social/tags/PEP723" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP723</span></a> "Inline script metadata"!</p>
earthling<p>A sea <a href="https://mastodon.social/tags/turtle" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>turtle</span></a> <a href="https://mastodon.social/tags/hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>hatchling</span></a> struggles to flip itself over at a beach in Adana, Turkey.</p><p>Photograph: Anadolu/Getty Images </p><p><span class="h-card" translate="no"><a href="https://a.gup.pe/u/photography" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>photography</span></a></span></p>
loganer<p><a href="https://mastodon.social/tags/Spider" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Spider</span></a> <a href="https://mastodon.social/tags/JumpingSpider" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>JumpingSpider</span></a> <a href="https://mastodon.social/tags/BoldJumpingSpider" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>BoldJumpingSpider</span></a> <a href="https://mastodon.social/tags/hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>hatchling</span></a> <br>little fellow sat on my hand for like half an hour and wouldn't leave XD</p><p>this is 1 of my many new roommates.</p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>Jak uprzejmie zasugerować komuś, że stworzony przezeń system budowania <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a> to typowe <a href="https://pol.social/tags/NIH" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>NIH</span></a>? Można tak:</p><p><a href="https://github.com/repo-helper/whey/issues/52" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/repo-helper/whey/is</span><span class="invisible">sues/52</span></a></p><p>No i tak, kompletne NIH, wymaga ConsoleKit (serio?!), wymaga kilku innych paczek NIH tego autora, i ma stale bota. No i praktycznie rzecz biorąc, jedynie autor używa tego wynalazku.</p><p>Więc dlaczego się tym przejmuję? Bo ten sam autor stworzył wtyczkę dla systemu budowania <a href="https://pol.social/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a>, hatch-requirements-txt, i ta wtyczka zależy od paczek, które używają wheya. No więc tak, mamy tu kolejny przykład osoby, która zrobiła jedną potencjalnie użyteczną paczkę (ja jej za taką nie uważam, ale inne projekty używają), i za jej pomocą wymusza na innych całą resztę swoich NIH-projektów.</p><p><a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a> <a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>How to politely point out that somebody's <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a> build system is utter <a href="https://social.treehouse.systems/tags/NIH" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>NIH</span></a>? Here's one whey… err, way:</p><p><a href="https://github.com/repo-helper/whey/issues/52" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/repo-helper/whey/is</span><span class="invisible">sues/52</span></a></p><p>And yes, it's complete NIH, with a dependency on ConsoleKit (seriously?!), a bunch of NIH packages, and a stale bot. On top of that, it's practically used only by its author.</p><p>So why do I care? Because the same person also made hatch-requirements-txt <a href="https://social.treehouse.systems/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> plugin, and said plugin depends on NIH packages (of course it does) using whey. So yeah, another case of making one potentially useful package (actually, I don't consider it useful, but random projects depend on it now) and using it to force your NIH projects on everyone.</p><p><a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a> <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a></p>
Tom<p>The baby snakes are out. We call them bull snakes but they are Great Basin gophersnakes. It is about a foot long. It was relocated to the tall grass.</p><p><a href="https://mastodon.social/tags/snakes" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>snakes</span></a> <a href="https://mastodon.social/tags/herps" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>herps</span></a> <a href="https://mastodon.social/tags/wildlife" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>wildlife</span></a> <a href="https://mastodon.social/tags/hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>hatchling</span></a> <a href="https://mastodon.social/tags/MastodonOnly" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>MastodonOnly</span></a></p>
Dave Diamond<p>Anybody else watching the <a href="https://mastodon.social/tags/CornellHawks" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CornellHawks</span></a> camera? There's a baby!! <a href="https://mastodon.social/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> <a href="https://mastodon.social/tags/RedTailedHawk" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RedTailedHawk</span></a> <a href="https://www.youtube.com/live/ndnr3bwdRzE?si=V1aMsP6Y3zo5y4QC" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">youtube.com/live/ndnr3bwdRzE?s</span><span class="invisible">i=V1aMsP6Y3zo5y4QC</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>Essentially, distro developers are firefighters, putting out fires made by careless upstreams.</p><p>What I've wasted time on, today:</p><p>- making the non-standalone test suite of <a href="https://social.treehouse.systems/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> (sigh) work without <a href="https://social.treehouse.systems/tags/UV" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>UV</span></a> again, so that a critical build dependency of a growing number of <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a> packages could be tested everywhere</p><p><a href="https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc6e54e1df5e0802198c793f39107a9028b8698f" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">gitweb.gentoo.org/repo/gentoo.</span><span class="invisible">git/commit/?id=cc6e54e1df5e0802198c793f39107a9028b8698f</span></a><br><a href="https://bugs.gentoo.org/930662" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">bugs.gentoo.org/930662</span><span class="invisible"></span></a></p><p>- fixing effectively dead (but with a promise of revival) <a href="https://social.treehouse.systems/tags/PassLib" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PassLib</span></a> not to break random stuff via printing warnings when using newer <a href="https://social.treehouse.systems/tags/BCrypt" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>BCrypt</span></a> versions</p><p><a href="https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c1e015b65b74283a51893672739c5e4784b95273" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">gitweb.gentoo.org/repo/gentoo.</span><span class="invisible">git/commit/?id=c1e015b65b74283a51893672739c5e4784b95273</span></a><br><a href="https://bugs.gentoo.org/925289" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">bugs.gentoo.org/925289</span><span class="invisible"></span></a></p><p>- hacking the test suite of <a href="https://social.treehouse.systems/tags/ImageIO" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ImageIO</span></a> work using an offline copy of test data, rather than cloning its git repository at the beginning of tests</p><p><a href="https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=77ff4bc09d68067f2c635d43d446f308990e0873" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">gitweb.gentoo.org/repo/gentoo.</span><span class="invisible">git/commit/?id=77ff4bc09d68067f2c635d43d446f308990e0873</span></a></p><p>I really wish people would consider donating to distro developers more often, rather than to projects that create this thankless work for us.</p><p><a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a></p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>W gruncie rzeczy, devowie distro są jak strażacy, walczący z pożarami wywołanymi przez nieostrożnych twórców oprogramowania.</p><p>Dzisiaj zmarnowałem czas na:</p><p>- naprawienie testów systemu budowania <a href="https://pol.social/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> (które nie są wyodrębnione od testów Hatcha, wzdych), by działały znów bez <a href="https://pol.social/tags/UV" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>UV</span></a>, abyśmy powtórnie mogli wszędzie testować tę krytyczną zależność rosnącej liczby paczek Pythona</p><p><a href="https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc6e54e1df5e0802198c793f39107a9028b8698f" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">gitweb.gentoo.org/repo/gentoo.</span><span class="invisible">git/commit/?id=cc6e54e1df5e0802198c793f39107a9028b8698f</span></a><br><a href="https://bugs.gentoo.org/930662" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">bugs.gentoo.org/930662</span><span class="invisible"></span></a></p><p>- naprawianie praktycznie martwej (ale z obietnicą resuscytacji) biblioteki <a href="https://pol.social/tags/PassLib" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PassLib</span></a>, by nie psuła przypadkowych paczek, wypisując ostrzeżenia z nowszymi wersjami biblioteki <a href="https://pol.social/tags/BCrypt" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>BCrypt</span></a></p><p><a href="https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c1e015b65b74283a51893672739c5e4784b95273" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">gitweb.gentoo.org/repo/gentoo.</span><span class="invisible">git/commit/?id=c1e015b65b74283a51893672739c5e4784b95273</span></a><br><a href="https://bugs.gentoo.org/925289" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">bugs.gentoo.org/925289</span><span class="invisible"></span></a></p><p>- obchodzenie upierdliwości w <a href="https://pol.social/tags/ImageIO" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ImageIO</span></a> tak, by dało się tę bibliotekę testować offline, z pobranymi wcześniej danymi, zamiast przy każdym uruchomieniu testów klonować repozytorium git</p><p><a href="https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=77ff4bc09d68067f2c635d43d446f308990e0873" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">gitweb.gentoo.org/repo/gentoo.</span><span class="invisible">git/commit/?id=77ff4bc09d68067f2c635d43d446f308990e0873</span></a></p><p>Naprawdę chciałbym, by ludzie częściej rozważali wsparcie devów distro, a nie tylko projektów, które tworzą im tę niewdzięczną pracę.</p><p><a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a></p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>Po otrzymaniu kolejnego zgłoszenia błędu, że pythonowa paczka (tym razem <a href="https://pol.social/tags/VirtualEnv" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>VirtualEnv</span></a>) nie buduje się, bo użytkownik nie ma dostatecznie nowej wersji paczki <a href="https://pol.social/tags/TroveClassifiers" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>TroveClassifiers</span></a>, zgłosiłem wniosek o to, by <a href="https://pol.social/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> uczyniło weryfikację "trove classifiers" opcjonalną, albo przynajmniej nie traktowało jej niepowodzenia jako błędu.</p><p>W tej chwili z tym się po prostu nie da ujechać. Technicznie rzecz biorąc, każda paczka musiałaby deklarować *minimalną* wersję paczki `trove-classifiers`, która dostarcza niezbędne im identyfikatory, a my musielibyśmy kopiować te specyfikacje do ebuildów w <a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a>. Jednakże to mało prawdopodobne, więc w praktyce zmuszeni jesteśmy sprawdzać&nbsp;wszystkie identyfikatory, używane przez paczki, i dopasowywać je do wersji `trove-classifiers`. Albo — bardziej realistycznie — zawsze wymagać najnowszej dostępnej wersji, i mieć nadzieję,&nbsp;że nie zapomnimy regularnie aktualizować tej zależności.</p><p><a href="https://github.com/pypa/hatch/issues/1368" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/hatch/issues/1</span><span class="invisible">368</span></a><br><a href="https://bugs.gentoo.org/928447" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">bugs.gentoo.org/928447</span><span class="invisible"></span></a></p><p><a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a> <a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>After getting yet another bug report about <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a> package (this time <a href="https://social.treehouse.systems/tags/VirtualEnv" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>VirtualEnv</span></a>) failing to build, because the user did not have new enough <a href="https://social.treehouse.systems/tags/TroveClassifiers" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>TroveClassifiers</span></a> installed, I've filed a bug asking <a href="https://social.treehouse.systems/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> to make trove classifier validation either optional or non-fatal.</p><p>Right now this simply is not feasible. Technically, every package would need to specify a *minimal* `trove-classifiers` package dependency based on the classifiers they used, and we would have to keep these versions in every <a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a> ebuild. However, that's unlikely to ever happen, so we'd actually have to check all listed trove classifiers and map them back to package versions. Or, more realistically, just always depend on the newest trove-classifiers available and hope we don't forget to update the dependency.</p><p><a href="https://github.com/pypa/hatch/issues/1368" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/pypa/hatch/issues/1</span><span class="invisible">368</span></a><br><a href="https://bugs.gentoo.org/928447" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">bugs.gentoo.org/928447</span><span class="invisible"></span></a></p><p><a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a> <a href="https://social.treehouse.systems/tags/packaging" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>packaging</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>To quote myself:</p><p>"""<br>Honestly, I think the biggest problem here is that <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a> <a href="https://social.treehouse.systems/tags/packaging" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>packaging</span></a> is infinitely complex and counter-intuitive, which means that anyone involved on either end is surprised to find a very high barrier of entry. The <a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a> Python Guide has already 300 KiB of .rst files, and it is by no means comprehensive. At this point, distribution developers pretty much can't really package anything written in Python without getting a special training and/or senior developer review, and even senior developers have a hard time following the constantly changing landscape.</p><p>At the same time, Python framework in Gentoo has already a bunch of safety checks included to detect the most common pitfalls. Again, it is by no means comprehensive and I keep extending it whenever we discover yet another counterintuitive pitfall. This thread makes me think that we will need to add another check to make sure that PKG-INFO is dealt with when pyproject.toml is patched.<br>"""</p><p><a href="https://discuss.python.org/t/respecting-core-metadata-2-2-when-building-from-source-distributions/48886/47" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">discuss.python.org/t/respectin</span><span class="invisible">g-core-metadata-2-2-when-building-from-source-distributions/48886/47</span></a></p><p><a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a> <a href="https://social.treehouse.systems/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a></p>
mgorny-nyan (on) :autism:🙀🚂🐧<p>Cytując siebie (i tłumacząc):</p><p>"""<br>Szczerze mówiąc, uważam, że największym problemem jest to, że dystrybucja oprogramowania w Pythonie jest nieskończenie skomplikowana i nieintuicyjna, co oznacza, że każda osoba, która chce się&nbsp;tym zająć z którejkolwiek strony, ku swojemu zaskoczeniu odkryje bardzo wysoki próg wejścia. <a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a> <a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a> Guide ma już 300 KiB plików .rst, i w żaden sposób nie jest kompletne. W tej chwili, przeciętny dev nie jest w stanie wrzucić czegokolwiek napisanego w Pythonie do dystrybucji, nie przechodząc wcześniej specjalnego szkolenia i/lub otrzymując przeglądu kodu od kogoś bardziej doświadczonego, a i owi seniorzy mają sporą trudność w nadążaniu za ciągłymi zmianami.</p><p>Jednocześnie, framework Pythona w Gentoo ma już sporo zabezpieczeń, które wykrywają najczęstsze błędy. To jednak też nie jest w żaden sposób kompletne, i dokładam kolejne, ilekroć odkrywamy kolejną nieintuicyjną pułapkę. Z tego wątku odnoszę wrażenie, że będziemy musieli dodać kolejne zabezpieczenie, które będzie upewniać się, że kiedy pyproject.toml jest modyfikowany, zajęto się&nbsp;również PKG-INFO.<br>"""</p><p><a href="https://discuss.python.org/t/respecting-core-metadata-2-2-when-building-from-source-distributions/48886/47" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">discuss.python.org/t/respectin</span><span class="invisible">g-core-metadata-2-2-when-building-from-source-distributions/48886/47</span></a></p><p><a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a> <a href="https://pol.social/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a></p>
mgorny-nyan (he) :autism:🙀🚂🐧<p>There's an open discussion in <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a> packaging how `pyproject.toml` and `PKG-INFO` should interact in sdist. Long story short, new version of <a href="https://social.treehouse.systems/tags/Hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Hatchling</span></a> started taking `PKG-INFO` for granted. For distribution packagers, this means that patching `pyproject.toml` after unpacking sdist suddenly stopped working, and e.g. if you fixed dependency pins in it, hatchling would instead silently used pinned dependencies from `PKG-INFO`.</p><p>The discussion is still open, but there's already been some worrying comments, such as people should modify package versions when they patch them…</p><p><a href="https://discuss.python.org/t/respecting-core-metadata-2-2-when-building-from-source-distributions/48886" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">discuss.python.org/t/respectin</span><span class="invisible">g-core-metadata-2-2-when-building-from-source-distributions/48886</span></a></p><p><a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a> <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a></p>