Szczerze mówiąc, jestem wściekły, że versioningit istnieje. To jest gorsze niż wynajdywanie koła na nowo. To jest zbudowanie kwadratowego koła, reklamowanie go jako najlepszy wynalazek od czasu krojonego chleba i odmowa wsparcia okrągłych osi.

Wuchta wiary włożyła wuchtę roboty w setuptools-scm. Jest dobre, rozwiązano problemy, o których większość ludzi nawet nie myśli, jest przyjazne tworców paczek dystrybucji.

A versioningit reklamuje się jako "w odróżnieniu od innych, pozwalający na łatwe dostosowanie formatu wersji" (tłum. własne). No super. Powinniście się też pochwalić, że w odróżnieniu od innych obsługuje tylko dwa najczęstsze przypadki i odmawia wsparcia całej reszty.

https://github.com/jwodder/versioningit/issues/45

#Python #setuptools

Tanie obejście problemu paczek w Pythonie, które przypadkiem instalują `tests` (albo `examples`, itp.) przez błędne użycie `find_packages()`:

```
sed -i -e '/find_packages(/d' setup.py || die
```

Wykorzystuje nową logikę automatycznego wyszukiwania paczek w #setuptools, która powinna sprawdzić się dla większości projektów. W #Gentoo możemy zakładać, że odpowiednio nowa wersja setuptools jest zainstalowana.

https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/httpbin/httpbin-0.10.0.ebuild?id=665fade2ced1ca27d4dabd2bfa2ffb022c1a6c71#n36

#Python

@nobodyinperson

This is very useful, thank you! I've been meaning to start using #setuptools

#Python

Inne wiadomości ze świata #Python: nowy backend #pep517 #scikit-build-core okazuje się psuć #setuptools na jeszcze jeden sposób. Tym razem błąd zauważono przy wykorzystaniu #pdm-backend.

A, fail2ban też psuje. Może to ten sam problem.

scikit-build-core: https://github.com/scikit-build/scikit-build-core/issues/426
fail2ban: https://bugs.gentoo.org/909535
poprzedni bug (psuł rozszerzenia #RustLang): https://github.com/scikit-build/scikit-build-core/issues/413

Co więcej, #pydantic 2 wymaga #RustLang. Musiałem zamaskować 6 paczek, i wyłączyć niektóre funkcje w 4 kolejnych na profilach #Gentoo WD40.

Jakimś cudem jeszcze nie straciliśmy #setuptools (było blisko).

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0cfabe9eb60a4c01ba1b242f1db8a2fac279c170

#Python

Mieliśmy w #Gentoo wczoraj zgłoszony paskudny bug (na szczęście z tinderboksa, a nie prawdziwego systemu) — paczki #Python z rozszerzeniami #RustLang nie instalowały owych rozszerzeń.

ionen określił, że winę ponosi scikit-build-core. Ruszyłem do boju uzbrojony w print()y, i określiłem, że scikit-build-core i #setuptools-rust oba nadpisują metodę Distribution.has_ext_modules(). Jeśli ten pierwszy jest wywołany jako drugi w kolejności, to nadpisuje metodę nadpisaną wcześniej przez setuptools-rust i rozszerzenia w Ruście są ignorowane.

https://github.com/scikit-build/scikit-build-core/issues/413

#Gentoo had a very bad bug reported yesterday (fortunately hit by tinderbox, not real system) — #Python #RustLang packages not installing extensions.

ionen figured out scikit-build-core is to blame. I braced my print()s and determined that the cause is that both scikit-build-core and #setuptools-rust are overriding Distribution.has_ext_modules() method. If the entry point of the former is executed later, it overwrites setuptools-rust and Rust extensions are ignored.

https://github.com/scikit-build/scikit-build-core/issues/413

So, #Python is slowly abandoning `setup.py` which has served us well for years.

That's fine, there were some good reasons for doing that. I guess the approach taken by #Rust, #Go, and #NodeJS possibly gave some ideas there.

Question is, how does one migrate? #setuptools can do plug-ins, is there one that can analyse the `setup` object you create, and spit out a `pyproject.toml` file from it?

Also, can I ship a `setup.py` that reads the `pyproject.toml` and provides backward-compatibility?

TIL that `wheel` is not needed as build requirement when using `setuptools`! https://setuptools.pypa.io/en/latest/userguide/quickstart.html#basic-use

> Historically this documentation has unnecessarily listed `wheel` in the `requires` list, and many projects still do that. This is not recommended.

#setuptools #python #packaging #pypa

Decided it's about time I got to grips with the current #Python #packaging system, starting with using a pyproject.toml file. Then I find #setuptools (which seems to have a new version every week) stopped supporting Python 3.6 before it added pyproject.toml support. Python 3.6 is what's installed in my current #OpenSUSE 15.4 desktop machine.
https://packaging.python.org/en/latest/specifications/declaring-project-metadata/

Just sigh.

https://github.com/Nuitka/Nuitka/commit/5cdbe453617d5bda4e4a72d3b85d646e722868b8

#Python #setuptools

Remember when I was concerned that #setuptools-style namespace being already installed to system trigger DeprecationWarnings when pkg_resources are imported? Well, that's no longer a real problem…

…because 67.5.0+ now unconditionally emit a DeprecationWarning when pkg_resources are imported. Expecting a lot of #pytest-based test suites to start suddenly failing. Fortunately, #Gentoo should be mostly unaffected (we force -Wdefault).

https://github.com/pypa/setuptools/pull/3843

#Python

Pre-#pep420 #Python namespaces are deprecated for quite a while. #setuptools started warning about use of namespace_packages= arg, and importing pkg_resources can throw a lot of deprecation warnings about namespace_packages.txt installed by other packages.

We've been removing explicit namespaces in #Gentoo for a while but it wasn't complete. Now I'm working on making the eclass strip pkg_resources namespaces completely.

So I was thinking: now that pip does all builds isolated, let's get rid of #setuptools in ensurepip. Turns out they've already thought of that ;-).

https://github.com/python/cpython/pull/101039

#Python

To provide more context, I've pushed new pypi.eclass update up for review. It features two changes:

- sdist and wheel filenames are normalized by default
- #Gentoo versions are translated into common PEP 440 equivalents by default

The latter is painless, the former can be painful because #setuptools still don't follow PEP 625, so all packages using uppercase or dots need `--no-normalize`, sigh.

https://github.com/gentoo/gentoo/pull/29526

#Python

I've added a section on fixing poetry include issue to the #Gentoo #Python Guide, and updated the section on #setuptools installing stray test packages to cover declarative configs as well. Both can be now found in the QA chapter.

https://projects.gentoo.org/python/guide/qawarn.html#stray-top-level-files-in-site-packages

Good evening #hivemind. Best way to make #Python imports work for both #PyPI #package #builds and also when running as a #script? #python3 #pythonista #build #setuptools

Oh the joys of #Python #pep517.

So I was happy that #setuptools finally adapted for new packaging, and we could finally unblock it in #Gentoo.

Now I've discovered that pdm-pep517 (the legacy project, the one that was discontinued in favor of a rename/rewrite, after 4 packages started using it) requires old packaging. Blocker-class sigh.

Maybe I should just sed it into a flit-core and stop bothering.

Good news, eveeryone! #setuptools 67.0.0 is now in #Gentoo, and it unblocks dev-python/packaging upgrade.

https://setuptools.pypa.io/en/latest/history.html#v67-0-0

Note that this implies making setuptools more strict e.g. about version syntax, so some packages may explode due to invalid versions or dependencies. Particularly beware of `;` usage in one-line install_requires/extras_require: https://setuptools.pypa.io/en/latest/userguide/declarative_config.html#opt-2

#Python

Another #Python #setuptools discovery to brighten our day. It turns out that the `SETUPTOOLS_SCM_PRETEND_VERSION` trick we've been using to make GitHub archives installable doesn't guarantee that all files are installed.

So we're looking at 65 packages potentially installing a subset of their Python packages in #Gentoo right now. Most notably, `py.typed` markers could be msising.

https://github.com/jaraco/keyring/issues/621