Gamedev Mastodon

mgorny-nyan (on) :autism:🙀🚂🐧Więc uważacie, że wasz instalator do pythonowych paczek "wheel" jest spoko?A czy obsługuje tworzenie dowiązań symbolicznych pomiędzy plikami `.pyc` na różnych poziomach optymalizacji, żeby zaoszczędzić przestrzeń dyskową, kiedy są identyczne?A czy obsługuje tworzenie dowiązań symbolicznych pomiędzy wszystkimi plikami w różnych lokalizacjach (np. site-packages dla różnych implementacji Pythona), żeby zaoszczędzić sporo przestrzeni, kiedy instaluje się 6 identycznych kopii tej samej paczki?Rzecz jasna, dopiero się przekonam, ile to psuje, ale <a href="https://pol.social/tags/gpep517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#gpep517</a> 19 wyszedł z tymi funkcjami, i mam gotowe łatki dla <a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Gentoo</a>.<a href="https://pypi.org/project/gpep517/19/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://pypi.org/project/gpep517/19/</a> <a href="https://github.com/gentoo/gentoo/pull/41905" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://github.com/gentoo/gentoo/pull/41905</a><a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a> <a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a>

mgorny-nyan (he) :autism:🙀🚂🐧So you think your <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a> wheel installer is cool?And does it support symlinking `.pyc` files across optimization levels, so that you can save space when they are identical?And does it support symlinking all files across different install locations (e.g. site-packages for different Python implementations), so that you can save lots of space when you are installing 6 identical copies of the same package?Of course, I am about to find out how much these symlinks break, but <a href="https://social.treehouse.systems/tags/gpep517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#gpep517</a> 19 is out with support for all this, and <a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Gentoo</a> eclass patches are ready.<a href="https://pypi.org/project/gpep517/19/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://pypi.org/project/gpep517/19/</a> <a href="https://github.com/gentoo/gentoo/pull/41905" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://github.com/gentoo/gentoo/pull/41905</a><a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a>

mgorny-nyan (on) :autism:🙀🚂🐧Uwaga: <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#setuptools</a> ogłosiło, że `setup.py install` wyleci 2025-10-31.<a href="https://setuptools.pypa.io/en/latest/history.html#v80-1-0" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://setuptools.pypa.io/en/latest/history.html#v80-1-0</a><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a> <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a>

mgorny-nyan (he) :autism:🙀🚂🐧PSA: <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#setuptools</a> added a deadline for `setup.py install` removal: 2025-10-31.<a href="https://setuptools.pypa.io/en/latest/history.html#v80-1-0" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://setuptools.pypa.io/en/latest/history.html#v80-1-0</a><a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a> <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a> <a href="https://social.treehouse.systems/tags/packaging" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#packaging</a>

mgorny-nyan (he) :autism:🙀🚂🐧<a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a>: let's split build system backend from frontend.Practically all PEP517 build systems: bringing their own frontend.<a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a>

mgorny-nyan (on) :autism:🙀🚂🐧<a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a>: rozdzielmy część backendową systemu budowania od frontendów.Praktycznie wszystkie backendy PEP517: mają własny frontend.<a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a>

mgorny-nyan (he) :autism:🙀🚂🐧<a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Gentoo</a> is also going "full <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a>" now, or to be more precise, we are going to rip out the legacy code paths that used `setup.py install`. However, that doesn't mean that PEP517 support is a solved problem.1. There are still packages that require `setup.py install`, and either outright reject or ignore PEP517. And I'm not talking of dead packages but actively maintained projects. <a href="https://social.treehouse.systems/tags/Fail2Ban" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail2Ban</a> is a particularly notorious example (the way I see it, it's going to stop working sooner or later).2. Some packages that do work with PEP517 builds, still require some hacks to install correctly. Sometimes it means moving files around, sometimes installing some files manually, sometimes patching stuff.3. There are many packages that use the legacy setuptools backend to workaround their broken PEP517 port. Fortunately, these are at least easy to fix, provided you can convince upstream that actually altering sys.path is the correct solution.4. Finally, we have removed a fair bunch of "hopeless" packages.<a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a>

mgorny-nyan (on) :autism:🙀🚂🐧<a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Gentoo</a> przechodzi na "100% <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a>", a dokładniej, to usuwamy kod wspierający `setup.py install`. Nie oznacza to jednak, że ekosystem doczekał się bezproblemowego wsparcia dla tego standardu.1. Nadal mamy paczki, które wymagają `setup.py install`, i albo odrzucają, albo ignorują, PEP517. I nie mówię tu o nierozwijanych starociach, lecz aktywnych projektach. <a href="https://pol.social/tags/Fail2Ban" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail2Ban</a> jest tu przykładem wartym nagany (jestem przekonany, że prędzej czy później przestanie działać).2. Niektóre paczki działają, ale wymagają obejść. Czasem trzeba przerzucić pliki po instalacji, czasem trzeba doinstalować jakiś brakujący plik, a czasem coś połatać.3. Wiele paczek nadal wymaga przestarzałego ("legacy") backendu setuptools, by obejść problemy z portem na PEP517. Szczęśliwie, z reguły łatwo się je naprawia, o ile uda się przekonać autorów, że modyfikacja sys.path to właściwe rozwiązanie.4. No i sporo paczek, dla których "nie było nadziei", wyleciało.<a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a>

mgorny-nyan (on) :autism:🙀🚂🐧Skoro już ugaszono te największe pożary, porozmawiajmy o innych fajnych rzeczach, które dzieją się z <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#setuptools</a>.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ą wydano… tydzień temu.No więc setuptools praktycznie mówi nam, że mamy do wyboru: albo używać 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).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ę setuptools (np. do <77), żeby pozbyć się ostrzeżeń, a inne będą wymagać >=77 ze względu na nową konfigurację.W takim razie… może mają państwo ochotę porozmawiać o systemie budowania flit? Albo o hatchling?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.<a href="https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/config/_apply_pyprojecttoml.py#L100-L106" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/config/_apply_pyprojecttoml.py#L100-L106</a> <a href="https://web.archive.org/web/20250324035753/https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-files" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://web.archive.org/web/20250324035753/https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-files</a><a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a> <a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a>

mgorny-nyan (he) :autism:🙀🚂🐧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 noreferrer" target="_blank">#setuptools</a> are doing these days.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.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).And of course the <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a> community will tell you to solve the problem by pinning dependencies. And guess what happens when people put arbitrary pins (say, <77) to silence this deprecation warning, and other people have >=77 dependency, because they use the new variant.So… would you like to talk about flit, perhaps? Or hatchling?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.<a href="https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/config/_apply_pyprojecttoml.py#L100-L106" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/config/_apply_pyprojecttoml.py#L100-L106</a> <a href="https://web.archive.org/web/20250324035753/https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-files" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://web.archive.org/web/20250324035753/https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-files</a><a href="https://social.treehouse.systems/tags/packaging" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#packaging</a> <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a>

mgorny-nyan (on) :autism:🙀🚂🐧> Nowy system budowania <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a> zbudowany na "dziesiątkach lat doświadczenia w ekosystemie i pracy z oprogramowaniem enterprise w skali światowej." [tłum. własne]Sprawdza.> Cykliczne zależność od samego siebie, przez co w ogóle tego nie da się zbudować.<a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a>

mgorny-nyan (he) :autism:🙀🚂🐧> A new <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a> build system built on "decades of experience in the ecosystem and working on enterprise software at a global scale."Looks inside.> A cyclic dependency on itself, making bootstrap impossible.<a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a>

mgorny-nyan (on) :autism:🙀🚂🐧Porównajmy backendy <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a> dla paczek napisanych w samym Pythonie:<a href="https://pol.social/tags/flit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#flit</a>-core: 51 KiB archiwum źródłowe, bez zależności, instaluje się 0,05 s, ~150 KiB po zainstalowaniu, działa wszedzie <a href="https://pol.social/tags/UvBuild" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#UvBuild</a>: 300 KiB archiwum, wymaga ~250 zależności crate (54 MiB pobierania, ~600 MiB w .cargo), buduje się 1 min 20 s (na 12-wątkowym procesorze), 4,2 MiB po zainstalowaniu, wspiera kilkanaście platformI oczywiście, że flit-core ma szerszą funkcjonalność. Ale jestem przekonany, że gdzieś ktoś potrzebuje zaoszczędzić te kilka milisekund budowania paczek Pythona.<a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a> <a href="https://pol.social/tags/RustLang" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RustLang</a> <a href="https://pol.social/tags/uv" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#uv</a>

mgorny-nyan (he) :autism:🙀🚂🐧Let's compare <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a> backends for pure <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a> packages:<a href="https://social.treehouse.systems/tags/flit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#flit</a>-core: 51 KiB sdist, no dependencies, 0.05 s to install, ~150 KiB after installing, works everywhere <a href="https://social.treehouse.systems/tags/UvBuild" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#UvBuild</a>: 300 KiB sdist, requires ~250 crates (54 MiB download, ~600 MiB .cargo directory), 1 min 20 s to install (on a 12-thread system), 4.2 MiB after installing, supports a dozen platformsAnd yes, you guessed right, flit-core has more functionality. But I'm sure that there are performance-critical wheel building workflows that will benefit from these few milliseconds shaved off wheel building time.<a href="https://social.treehouse.systems/tags/RustLang" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RustLang</a> <a href="https://social.treehouse.systems/tags/uv" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#uv</a>

mgorny-nyan (on) :autism:🙀🚂🐧Jakby ktoś nie śledził, to informuję, że <a href="https://pol.social/tags/UvBuild" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#UvBuild</a> jednak powstaje — i to straszna wiadomość dla wszystkich tych, których system nie jest wspierany przez <a href="https://pol.social/tags/RustLang" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RustLang</a>.O co chodzi? Otóż, uv-build to system budowania <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a> dla projektów w "czystym" Pythonie (znaczy, bez kompilowanych rozszerzeń), który jest napisany w Ruście. Tak, dobrze wnioskujecie: budowanie niektórych paczek, które zawierają *wyłącznie pliki Pythona*, będzie teraz wymagało programu skompilowanego w Ruście.Co to oznacza dla mnie? Czeka ma tłumaczenie ludziom, raz po raz, że wybrali "zły" backend, i ich paczka teraz nie jest przenośna, i niektórzy użytkownicy <a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Gentoo</a> nie będą mogli już jej używać. Użeranie się z większą liczbą toksycznych ludzi, których po prostu nie obchodzą problemy innych, albo wprost wykorzystają sytuację, by kopnąć leżącego.Oczywiście, zawsze jest nadzieja, że ktoś napisze wersję w Pythonie, której będzie można używać w miejsce standardowej. Ale nie będzie to nic przyjemnego, bo mówimy o projekcie "z szybkim tempem rozwoju" — który wprost odrzucił utrzymanie dodatkowej wersji w Pythonie, "ze względu na ograniczenia czasowe i, jak wspominano w wątku, fundamentalne różnice zachowania pomiędzy bibliotekami standardowymi Rusta I Pythona" [tłum. własne].<a href="https://github.com/astral-sh/uv/issues/3957#issuecomment-2657825266" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://github.com/astral-sh/uv/issues/3957#issuecomment-2657825266</a><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a>

mgorny-nyan (he) :autism:🙀🚂🐧In case you aren't following the threads, <a href="https://social.treehouse.systems/tags/UvBuild" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#UvBuild</a> is happening after all — and that's horrible news for anyone whose platform isn't supported by <a href="https://social.treehouse.systems/tags/RustLang" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RustLang</a>.What's that all about? Well, uv-build is a <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a> backend for pure <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a> packages, that's written in Rust. Yes, that's what you think it means — building some *pure Python* packages will now require using a binary written in Rust now.What does that mean for me? Having to repeatedly explain to people that their build backend decision is a problem for the portability of their package, and that some of <a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Gentoo</a> users can't use it anymore. Having to deal even more with toxic people who are not interested in our problems, or who will even deliberately use this backend as an excuse to remove platform support.Though, there is always some hope that someone will write a drop-in pure Python replacement for the backend, though it's going to be a pain since we're talking of following a project with high "rate of development" — a project that explicitly rejected maintaining a pure Python fallback "due to time constraints and, as mentioned by some, foundational differences in behavior between the Rust and Python standard libraries".<a href="https://github.com/astral-sh/uv/issues/3957#issuecomment-2657825266" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://github.com/astral-sh/uv/issues/3957#issuecomment-2657825266</a>

mgorny-nyan (he) :autism:🙀🚂🐧Today I'm posting on the company blog:""" In 2017, <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a> changed the <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a> <a href="https://social.treehouse.systems/tags/packaging" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#packaging</a> landscape forever. Prior to it, the setuptools build system held a de facto monopoly. If you were to publish a Python package on PyPI, you either used setuptools, extended it or had to create something reasonably compatible with it. And given how many different options setuptools provided, and how various users used different combinations of these options, you were likely to spend a lot of effort implementing what you believed to be necessary, and still learn that someone's workflow does not work.PEP 517 enabled a ‘black box’ approach to building Python packages. A package needed only to name the backend it wished to use, and the backend implemented a few predefined functions to run the build process and create a source or binary distribution. This interface is well-defined and relatively simple. There are only two mandatory functions, and currently up to five optional — compared to 28 commands in setuptools (each with its own list of options).Unsurprisingly, many new build systems were created. Some of them focused on pure Python packages, others on integration with other build systems such as CMake, Meson or Cargo. It is clear that you can now choose between many new build systems. But how popular are they today? In this post, I would like to explore that. """<a href="https://labs.quansight.org/blog/pep-517-build-system-popularity" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://labs.quansight.org/blog/pep-517-build-system-popularity</a>

mgorny-nyan (on) :autism:🙀🚂🐧Okej, sprecyzujmy coś. <a href="https://pol.social/tags/PEP621" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP621</a> to nie jest końcowy standard, który unifikuje systemy budowania <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a>.Tak, to dobry standard. Tak, dostarcza jednolitą specyfikację dla metadanych paczek. Jednakże, pomijając już opcję "dynamicznych metadanych", które zależą od implementacji, to PEP 621 nie specyfikuje, w jaki sposób mają tworzone być paczki źródłowe albo binarne — na przykład, skąd należy brać kod Pythona do paczki. To wszystko jest nadal wyborem konkretnej implementacji.Dobra wiadomość: jeżeli paczka jest prosta jak konstrukcja cepa, i w miarę typowa, to najpewniej można w niej podmienić system budowania na inny zgodny z PEP 621, i będzie działać. Zła wiadomość: nie ma żadnej gwarancji. Rezultatem może być wszystko, od jakiś minimalnych różnic, do całkowicie dysfunkcyjnych paczek.<a href="https://peps.python.org/pep-0621" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://peps.python.org/pep-0621</a><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a>

mgorny-nyan (he) :autism:🙀🚂🐧Okay, let's get things clear. <a href="https://social.treehouse.systems/tags/PEP621" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP621</a> isn't the ultimate standard to unify <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a> build systems.Yes, it's a good standard. Yes, it specifies a uniform format for specifying baseline package metadata. However, besides allowing for implementation-defined dynamic metadata, it does not specify anything related to how the source distributions and wheels are actually created — where to take Python packages from, for example. All these things are still implementation-defined.Good news is, if your package has a trivial and common enough layout, then you can probably switch between different PEP 621-compliant build systems and things will just work. Bad news is, there's no guarantee of that. You may as well get anything from slight packaging differences to completely dysfunctional wheels and/or sdists.<a href="https://peps.python.org/pep-0621" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://peps.python.org/pep-0621</a>

mgorny-nyan (on) :autism:🙀🚂🐧A tak na marginesie, zdaje się, że jedyny powód, dla którego <a href="https://pol.social/tags/setuptools" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#setuptools</a> jeszcze istnieje, to dawanie ludziom wymówek, żeby tworzyli nowe backendy <a href="https://pol.social/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PEP517</a>. No, bo w porównaniu z setuptools to każdy wydaje się znacznie lepszy.<a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Gentoo</a> <a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Python</a>

Recent searches

Search options

Administered by:

Server stats:

#pep517