#gentoo — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #gentoo, aggregated by home.social.
-
Zero days since it turned out that #GnuPG has arbitrarily changed behavior between versions in the name of "safe default", and required you to pass an additional option to make it behave properly in the rare cases it matters. Of course we still need to support old versions and alternative implementations without that option. And of course there is no clean way of checking whether it's available or not.
-
Zero days since it turned out that #GnuPG has arbitrarily changed behavior between versions in the name of "safe default", and required you to pass an additional option to make it behave properly in the rare cases it matters. Of course we still need to support old versions and alternative implementations without that option. And of course there is no clean way of checking whether it's available or not.
-
Zero days since it turned out that #GnuPG has arbitrarily changed behavior between versions in the name of "safe default", and required you to pass an additional option to make it behave properly in the rare cases it matters. Of course we still need to support old versions and alternative implementations without that option. And of course there is no clean way of checking whether it's available or not.
-
Zero days since it turned out that #GnuPG has arbitrarily changed behavior between versions in the name of "safe default", and required you to pass an additional option to make it behave properly in the rare cases it matters. Of course we still need to support old versions and alternative implementations without that option. And of course there is no clean way of checking whether it's available or not.
-
Zero days since it turned out that #GnuPG has arbitrarily changed behavior between versions in the name of "safe default", and required you to pass an additional option to make it behave properly in the rare cases it matters. Of course we still need to support old versions and alternative implementations without that option. And of course there is no clean way of checking whether it's available or not.
-
Dziś ktoś pytał w temacie walki z ostrzeżeniami o "przestarzałej" funkcjonalności w #setuptools (w #Gentoo zbieramy je i wypisujemy ponownie, więc ludzie faktycznie mogą je zauważyć). Myślę, że moją najlepszą podpowiedzią było: użyj innego systemu budowania.
-
Dziś ktoś pytał w temacie walki z ostrzeżeniami o "przestarzałej" funkcjonalności w #setuptools (w #Gentoo zbieramy je i wypisujemy ponownie, więc ludzie faktycznie mogą je zauważyć). Myślę, że moją najlepszą podpowiedzią było: użyj innego systemu budowania.
-
Dziś ktoś pytał w temacie walki z ostrzeżeniami o "przestarzałej" funkcjonalności w #setuptools (w #Gentoo zbieramy je i wypisujemy ponownie, więc ludzie faktycznie mogą je zauważyć). Myślę, że moją najlepszą podpowiedzią było: użyj innego systemu budowania.
-
Dziś ktoś pytał w temacie walki z ostrzeżeniami o "przestarzałej" funkcjonalności w #setuptools (w #Gentoo zbieramy je i wypisujemy ponownie, więc ludzie faktycznie mogą je zauważyć). Myślę, że moją najlepszą podpowiedzią było: użyj innego systemu budowania.
-
Someone asked about fixing #setuptools deprecation warnings today (#Gentoo collects and reprints them, so people actually notice). I think my best hint is: use another build system.
-
Someone asked about fixing #setuptools deprecation warnings today (#Gentoo collects and reprints them, so people actually notice). I think my best hint is: use another build system.
-
Someone asked about fixing #setuptools deprecation warnings today (#Gentoo collects and reprints them, so people actually notice). I think my best hint is: use another build system.
-
Someone asked about fixing #setuptools deprecation warnings today (#Gentoo collects and reprints them, so people actually notice). I think my best hint is: use another build system.
-
Someone asked about fixing #setuptools deprecation warnings today (#Gentoo collects and reprints them, so people actually notice). I think my best hint is: use another build system.
-
Biblioteki eclass związane z Pythonem w #Gentoo są całkiem aktualne. Stosują się do aktualnych zaleceń i standardów, i usuwają na bieżąco rzeczy przestarzałe. Niemniej, mają za sobą długą historię, i najlepiej chyba to widać po nazewnictwie.
Biblioteki te powstały w celu zastąpienia wcześniejszych "distutils" i "python". Dlatego też nazwałem je odpowiednio "distutils-r1" i "python-r1", podążając za schematem rewizji dla ebuildów. Dla spójności, pozostałe biblioteki również doczekały się sufiksu "-r1": "python-any-r1", "python-single-r1" i "python-utils-r1" — mimo że nigdy nie istniały w wersji "r0".
Wkrótce poznałem swój pierwszy błąd. Uczyniłem bibliotekę odpowiedzialną za budowanie paczek dla wielu implementacji "domyślną", prawdopodobnie w oparciu o ówczesne rekomendacje pisania ebuildów. Jednak z czasem odkryłem, że w większości przypadków (tam, gdzie nie używamy "distutils-r1") nie potrzeba takiej funkcjonalności, a ebuildy stają się niepotrzebne skomplikowane. Gdybym wybierał nazwy dzisiaj, najpewniej nazwałbym ją "python-multi", żeby podkreślić zastosowanie. A "domyślnej" albo by nie było w ogóle, albo byłaby nią "python-single".
Z "distutils-r1" jest jeszcze gorzej. Oczywiście, kiedy powstawała, distutils wciąż istniało, a niektórzy ludzie (jak ja) preferowali je nad zależnością od setuptools. A dziś zostało już całkiem pochłonięte przez setuptools, a za sprawą #PEP517 nawet "setuptools" nie jest już dobrą nazwą. No i ludzie dziwią się, że np. dla systemu budowania Hatchling mają używać "distutils-r1".
No i to już jest coś, co mogłem zrobić lepiej. Wprowadzenie wsparcia PEP517 była sporą zmianą, i zamiast dodawać zmienną DISTUTILS_USE_PEP517 (nazwa ze sprzecznością), mogłem utworzyć nową bibliotekę. Dlaczego tego nie zrobiłem? Cóż, jeden i drugi tryb dzieliły ze sobą sporo kodu, i nie było sensu go duplikować. Oczywiście, z czasem wspólnego kodu było trochę mniej, i w końcu wsparcie starego trybu wyleciało — ale to już po ptakach.
(1/2)
-
Biblioteki eclass związane z Pythonem w #Gentoo są całkiem aktualne. Stosują się do aktualnych zaleceń i standardów, i usuwają na bieżąco rzeczy przestarzałe. Niemniej, mają za sobą długą historię, i najlepiej chyba to widać po nazewnictwie.
Biblioteki te powstały w celu zastąpienia wcześniejszych "distutils" i "python". Dlatego też nazwałem je odpowiednio "distutils-r1" i "python-r1", podążając za schematem rewizji dla ebuildów. Dla spójności, pozostałe biblioteki również doczekały się sufiksu "-r1": "python-any-r1", "python-single-r1" i "python-utils-r1" — mimo że nigdy nie istniały w wersji "r0".
Wkrótce poznałem swój pierwszy błąd. Uczyniłem bibliotekę odpowiedzialną za budowanie paczek dla wielu implementacji "domyślną", prawdopodobnie w oparciu o ówczesne rekomendacje pisania ebuildów. Jednak z czasem odkryłem, że w większości przypadków (tam, gdzie nie używamy "distutils-r1") nie potrzeba takiej funkcjonalności, a ebuildy stają się niepotrzebne skomplikowane. Gdybym wybierał nazwy dzisiaj, najpewniej nazwałbym ją "python-multi", żeby podkreślić zastosowanie. A "domyślnej" albo by nie było w ogóle, albo byłaby nią "python-single".
Z "distutils-r1" jest jeszcze gorzej. Oczywiście, kiedy powstawała, distutils wciąż istniało, a niektórzy ludzie (jak ja) preferowali je nad zależnością od setuptools. A dziś zostało już całkiem pochłonięte przez setuptools, a za sprawą #PEP517 nawet "setuptools" nie jest już dobrą nazwą. No i ludzie dziwią się, że np. dla systemu budowania Hatchling mają używać "distutils-r1".
No i to już jest coś, co mogłem zrobić lepiej. Wprowadzenie wsparcia PEP517 była sporą zmianą, i zamiast dodawać zmienną DISTUTILS_USE_PEP517 (nazwa ze sprzecznością), mogłem utworzyć nową bibliotekę. Dlaczego tego nie zrobiłem? Cóż, jeden i drugi tryb dzieliły ze sobą sporo kodu, i nie było sensu go duplikować. Oczywiście, z czasem wspólnego kodu było trochę mniej, i w końcu wsparcie starego trybu wyleciało — ale to już po ptakach.
(1/2)
-
Biblioteki eclass związane z Pythonem w #Gentoo są całkiem aktualne. Stosują się do aktualnych zaleceń i standardów, i usuwają na bieżąco rzeczy przestarzałe. Niemniej, mają za sobą długą historię, i najlepiej chyba to widać po nazewnictwie.
Biblioteki te powstały w celu zastąpienia wcześniejszych "distutils" i "python". Dlatego też nazwałem je odpowiednio "distutils-r1" i "python-r1", podążając za schematem rewizji dla ebuildów. Dla spójności, pozostałe biblioteki również doczekały się sufiksu "-r1": "python-any-r1", "python-single-r1" i "python-utils-r1" — mimo że nigdy nie istniały w wersji "r0".
Wkrótce poznałem swój pierwszy błąd. Uczyniłem bibliotekę odpowiedzialną za budowanie paczek dla wielu implementacji "domyślną", prawdopodobnie w oparciu o ówczesne rekomendacje pisania ebuildów. Jednak z czasem odkryłem, że w większości przypadków (tam, gdzie nie używamy "distutils-r1") nie potrzeba takiej funkcjonalności, a ebuildy stają się niepotrzebne skomplikowane. Gdybym wybierał nazwy dzisiaj, najpewniej nazwałbym ją "python-multi", żeby podkreślić zastosowanie. A "domyślnej" albo by nie było w ogóle, albo byłaby nią "python-single".
Z "distutils-r1" jest jeszcze gorzej. Oczywiście, kiedy powstawała, distutils wciąż istniało, a niektórzy ludzie (jak ja) preferowali je nad zależnością od setuptools. A dziś zostało już całkiem pochłonięte przez setuptools, a za sprawą #PEP517 nawet "setuptools" nie jest już dobrą nazwą. No i ludzie dziwią się, że np. dla systemu budowania Hatchling mają używać "distutils-r1".
No i to już jest coś, co mogłem zrobić lepiej. Wprowadzenie wsparcia PEP517 była sporą zmianą, i zamiast dodawać zmienną DISTUTILS_USE_PEP517 (nazwa ze sprzecznością), mogłem utworzyć nową bibliotekę. Dlaczego tego nie zrobiłem? Cóż, jeden i drugi tryb dzieliły ze sobą sporo kodu, i nie było sensu go duplikować. Oczywiście, z czasem wspólnego kodu było trochę mniej, i w końcu wsparcie starego trybu wyleciało — ale to już po ptakach.
(1/2)
-
Biblioteki eclass związane z Pythonem w #Gentoo są całkiem aktualne. Stosują się do aktualnych zaleceń i standardów, i usuwają na bieżąco rzeczy przestarzałe. Niemniej, mają za sobą długą historię, i najlepiej chyba to widać po nazewnictwie.
Biblioteki te powstały w celu zastąpienia wcześniejszych "distutils" i "python". Dlatego też nazwałem je odpowiednio "distutils-r1" i "python-r1", podążając za schematem rewizji dla ebuildów. Dla spójności, pozostałe biblioteki również doczekały się sufiksu "-r1": "python-any-r1", "python-single-r1" i "python-utils-r1" — mimo że nigdy nie istniały w wersji "r0".
Wkrótce poznałem swój pierwszy błąd. Uczyniłem bibliotekę odpowiedzialną za budowanie paczek dla wielu implementacji "domyślną", prawdopodobnie w oparciu o ówczesne rekomendacje pisania ebuildów. Jednak z czasem odkryłem, że w większości przypadków (tam, gdzie nie używamy "distutils-r1") nie potrzeba takiej funkcjonalności, a ebuildy stają się niepotrzebne skomplikowane. Gdybym wybierał nazwy dzisiaj, najpewniej nazwałbym ją "python-multi", żeby podkreślić zastosowanie. A "domyślnej" albo by nie było w ogóle, albo byłaby nią "python-single".
Z "distutils-r1" jest jeszcze gorzej. Oczywiście, kiedy powstawała, distutils wciąż istniało, a niektórzy ludzie (jak ja) preferowali je nad zależnością od setuptools. A dziś zostało już całkiem pochłonięte przez setuptools, a za sprawą #PEP517 nawet "setuptools" nie jest już dobrą nazwą. No i ludzie dziwią się, że np. dla systemu budowania Hatchling mają używać "distutils-r1".
No i to już jest coś, co mogłem zrobić lepiej. Wprowadzenie wsparcia PEP517 była sporą zmianą, i zamiast dodawać zmienną DISTUTILS_USE_PEP517 (nazwa ze sprzecznością), mogłem utworzyć nową bibliotekę. Dlaczego tego nie zrobiłem? Cóż, jeden i drugi tryb dzieliły ze sobą sporo kodu, i nie było sensu go duplikować. Oczywiście, z czasem wspólnego kodu było trochę mniej, i w końcu wsparcie starego trybu wyleciało — ale to już po ptakach.
(1/2)
-
So #Gentoo #Python eclasses are pretty modern, in the sense that they tend to follow the best practices and standards, and eventually deal with deprecations. Nevertheless, they have a long history and carry quite some historical burden, particularly regarding to naming.
The key point is that the eclasses were conceived as a replacement for the old eclasses: "distutils" and "python". Hence, much like we revision ebuilds, I've named the matching eclasses "distutils-r1" and "python-r1". For consistency, I've also used the "-r1" suffix for the remaining eclasses introduced at the time: "python-any-r1", "python-single-r1" and "python-utils-r1" — even though there were never "r0"s.
It didn't take long to realize my first mistake. I've made the multi-impl eclass effectively the "main" eclass, probably largely inspired by the previous Gentoo recommendations. However, in the end I've found out that for the most use cases (i.e. where "distutils-r1" is not involved), there is no real need for multi-impl, and it makes things much harder. So if I were naming them today, I would have named it "python-multi", to indicate the specific use case — and either avoid designating a default at all, or made "python-single" the default.
What aged even worse is the "distutils-r1" eclass. Admittedly, back when it was conceived, distutils was still largely a thing — and there were people (like me) who avoided unnecessary dependency on setuptools. Of course, nowadays it has been entirely devoured by setuptools, and with #PEP517 even "setuptools" wouldn't be a good name anymore. Nowadays, people are getting confused why they are supposed to use "distutils-r1" for, say, Hatchling.
Admittedly, this is something I could have done differently — PEP517 support was a major migration, and involved an explicit switch. Instead of adding DISTUTILS_USE_PEP517 (what a self-contradictory name) variable, I could have forked the eclass. Why didn't I do that? Because there used to be a lot of code shared between the two paths. Of course, over time they diverged more, and eventually I've dropped the legacy support — but the opportunity to rename was lost.
In fact, as a semi-related fact, I've recognized another design problem with the eclass earlier — I should have gone for two eclasses rather than one: a "python-phase" eclass with generic sub-phase support, and a "distutils" (or later "python-pep517") implementing default sub-phases for the common backends. And again, this is precisely how I could have solved the code reuse problem when I introduced PEP517 support.
But then, I didn't anticipate how the eclasses would end up looking like in the end — and I can't really predict what new challenges the Python ecosystem is going to bring us. And I think it's too late to rename or split stuff — too much busywork on everyone.
-
So #Gentoo #Python eclasses are pretty modern, in the sense that they tend to follow the best practices and standards, and eventually deal with deprecations. Nevertheless, they have a long history and carry quite some historical burden, particularly regarding to naming.
The key point is that the eclasses were conceived as a replacement for the old eclasses: "distutils" and "python". Hence, much like we revision ebuilds, I've named the matching eclasses "distutils-r1" and "python-r1". For consistency, I've also used the "-r1" suffix for the remaining eclasses introduced at the time: "python-any-r1", "python-single-r1" and "python-utils-r1" — even though there were never "r0"s.
It didn't take long to realize my first mistake. I've made the multi-impl eclass effectively the "main" eclass, probably largely inspired by the previous Gentoo recommendations. However, in the end I've found out that for the most use cases (i.e. where "distutils-r1" is not involved), there is no real need for multi-impl, and it makes things much harder. So if I were naming them today, I would have named it "python-multi", to indicate the specific use case — and either avoid designating a default at all, or made "python-single" the default.
What aged even worse is the "distutils-r1" eclass. Admittedly, back when it was conceived, distutils was still largely a thing — and there were people (like me) who avoided unnecessary dependency on setuptools. Of course, nowadays it has been entirely devoured by setuptools, and with #PEP517 even "setuptools" wouldn't be a good name anymore. Nowadays, people are getting confused why they are supposed to use "distutils-r1" for, say, Hatchling.
Admittedly, this is something I could have done differently — PEP517 support was a major migration, and involved an explicit switch. Instead of adding DISTUTILS_USE_PEP517 (what a self-contradictory name) variable, I could have forked the eclass. Why didn't I do that? Because there used to be a lot of code shared between the two paths. Of course, over time they diverged more, and eventually I've dropped the legacy support — but the opportunity to rename was lost.
In fact, as a semi-related fact, I've recognized another design problem with the eclass earlier — I should have gone for two eclasses rather than one: a "python-phase" eclass with generic sub-phase support, and a "distutils" (or later "python-pep517") implementing default sub-phases for the common backends. And again, this is precisely how I could have solved the code reuse problem when I introduced PEP517 support.
But then, I didn't anticipate how the eclasses would end up looking like in the end — and I can't really predict what new challenges the Python ecosystem is going to bring us. And I think it's too late to rename or split stuff — too much busywork on everyone.
-
So #Gentoo #Python eclasses are pretty modern, in the sense that they tend to follow the best practices and standards, and eventually deal with deprecations. Nevertheless, they have a long history and carry quite some historical burden, particularly regarding to naming.
The key point is that the eclasses were conceived as a replacement for the old eclasses: "distutils" and "python". Hence, much like we revision ebuilds, I've named the matching eclasses "distutils-r1" and "python-r1". For consistency, I've also used the "-r1" suffix for the remaining eclasses introduced at the time: "python-any-r1", "python-single-r1" and "python-utils-r1" — even though there were never "r0"s.
It didn't take long to realize my first mistake. I've made the multi-impl eclass effectively the "main" eclass, probably largely inspired by the previous Gentoo recommendations. However, in the end I've found out that for the most use cases (i.e. where "distutils-r1" is not involved), there is no real need for multi-impl, and it makes things much harder. So if I were naming them today, I would have named it "python-multi", to indicate the specific use case — and either avoid designating a default at all, or made "python-single" the default.
What aged even worse is the "distutils-r1" eclass. Admittedly, back when it was conceived, distutils was still largely a thing — and there were people (like me) who avoided unnecessary dependency on setuptools. Of course, nowadays it has been entirely devoured by setuptools, and with #PEP517 even "setuptools" wouldn't be a good name anymore. Nowadays, people are getting confused why they are supposed to use "distutils-r1" for, say, Hatchling.
Admittedly, this is something I could have done differently — PEP517 support was a major migration, and involved an explicit switch. Instead of adding DISTUTILS_USE_PEP517 (what a self-contradictory name) variable, I could have forked the eclass. Why didn't I do that? Because there used to be a lot of code shared between the two paths. Of course, over time they diverged more, and eventually I've dropped the legacy support — but the opportunity to rename was lost.
In fact, as a semi-related fact, I've recognized another design problem with the eclass earlier — I should have gone for two eclasses rather than one: a "python-phase" eclass with generic sub-phase support, and a "distutils" (or later "python-pep517") implementing default sub-phases for the common backends. And again, this is precisely how I could have solved the code reuse problem when I introduced PEP517 support.
But then, I didn't anticipate how the eclasses would end up looking like in the end — and I can't really predict what new challenges the Python ecosystem is going to bring us. And I think it's too late to rename or split stuff — too much busywork on everyone.
-
So #Gentoo #Python eclasses are pretty modern, in the sense that they tend to follow the best practices and standards, and eventually deal with deprecations. Nevertheless, they have a long history and carry quite some historical burden, particularly regarding to naming.
The key point is that the eclasses were conceived as a replacement for the old eclasses: "distutils" and "python". Hence, much like we revision ebuilds, I've named the matching eclasses "distutils-r1" and "python-r1". For consistency, I've also used the "-r1" suffix for the remaining eclasses introduced at the time: "python-any-r1", "python-single-r1" and "python-utils-r1" — even though there were never "r0"s.
It didn't take long to realize my first mistake. I've made the multi-impl eclass effectively the "main" eclass, probably largely inspired by the previous Gentoo recommendations. However, in the end I've found out that for the most use cases (i.e. where "distutils-r1" is not involved), there is no real need for multi-impl, and it makes things much harder. So if I were naming them today, I would have named it "python-multi", to indicate the specific use case — and either avoid designating a default at all, or made "python-single" the default.
What aged even worse is the "distutils-r1" eclass. Admittedly, back when it was conceived, distutils was still largely a thing — and there were people (like me) who avoided unnecessary dependency on setuptools. Of course, nowadays it has been entirely devoured by setuptools, and with #PEP517 even "setuptools" wouldn't be a good name anymore. Nowadays, people are getting confused why they are supposed to use "distutils-r1" for, say, Hatchling.
Admittedly, this is something I could have done differently — PEP517 support was a major migration, and involved an explicit switch. Instead of adding DISTUTILS_USE_PEP517 (what a self-contradictory name) variable, I could have forked the eclass. Why didn't I do that? Because there used to be a lot of code shared between the two paths. Of course, over time they diverged more, and eventually I've dropped the legacy support — but the opportunity to rename was lost.
In fact, as a semi-related fact, I've recognized another design problem with the eclass earlier — I should have gone for two eclasses rather than one: a "python-phase" eclass with generic sub-phase support, and a "distutils" (or later "python-pep517") implementing default sub-phases for the common backends. And again, this is precisely how I could have solved the code reuse problem when I introduced PEP517 support.
But then, I didn't anticipate how the eclasses would end up looking like in the end — and I can't really predict what new challenges the Python ecosystem is going to bring us. And I think it's too late to rename or split stuff — too much busywork on everyone.
-
So #Gentoo #Python eclasses are pretty modern, in the sense that they tend to follow the best practices and standards, and eventually deal with deprecations. Nevertheless, they have a long history and carry quite some historical burden, particularly regarding to naming.
The key point is that the eclasses were conceived as a replacement for the old eclasses: "distutils" and "python". Hence, much like we revision ebuilds, I've named the matching eclasses "distutils-r1" and "python-r1". For consistency, I've also used the "-r1" suffix for the remaining eclasses introduced at the time: "python-any-r1", "python-single-r1" and "python-utils-r1" — even though there were never "r0"s.
It didn't take long to realize my first mistake. I've made the multi-impl eclass effectively the "main" eclass, probably largely inspired by the previous Gentoo recommendations. However, in the end I've found out that for the most use cases (i.e. where "distutils-r1" is not involved), there is no real need for multi-impl, and it makes things much harder. So if I were naming them today, I would have named it "python-multi", to indicate the specific use case — and either avoid designating a default at all, or made "python-single" the default.
What aged even worse is the "distutils-r1" eclass. Admittedly, back when it was conceived, distutils was still largely a thing — and there were people (like me) who avoided unnecessary dependency on setuptools. Of course, nowadays it has been entirely devoured by setuptools, and with #PEP517 even "setuptools" wouldn't be a good name anymore. Nowadays, people are getting confused why they are supposed to use "distutils-r1" for, say, Hatchling.
Admittedly, this is something I could have done differently — PEP517 support was a major migration, and involved an explicit switch. Instead of adding DISTUTILS_USE_PEP517 (what a self-contradictory name) variable, I could have forked the eclass. Why didn't I do that? Because there used to be a lot of code shared between the two paths. Of course, over time they diverged more, and eventually I've dropped the legacy support — but the opportunity to rename was lost.
In fact, as a semi-related fact, I've recognized another design problem with the eclass earlier — I should have gone for two eclasses rather than one: a "python-phase" eclass with generic sub-phase support, and a "distutils" (or later "python-pep517") implementing default sub-phases for the common backends. And again, this is precisely how I could have solved the code reuse problem when I introduced PEP517 support.
But then, I didn't anticipate how the eclasses would end up looking like in the end — and I can't really predict what new challenges the Python ecosystem is going to bring us. And I think it's too late to rename or split stuff — too much busywork on everyone.
-
New reason not to use #PythonPoetry just dropped: they reinvented "reproducible builds", poorly. The problem is, they missed the purpose of reproducible builds entirely and they use it for source distributions too, and when you don't use SOURCE_DATE_EPOCH, they force all files to epoch (as in timestamp 0) instead of leaving them alone.
Like, all source distributions created by Poetry and uploaded to #PyPI now have 1970 timestamps that, simply speaking, break stuff. The most absurd thing is that ZIP can't handle that timestamp, so they override it and use another date for wheels 🤦.
-
New reason not to use #PythonPoetry just dropped: they reinvented "reproducible builds", poorly. The problem is, they missed the purpose of reproducible builds entirely and they use it for source distributions too, and when you don't use SOURCE_DATE_EPOCH, they force all files to epoch (as in timestamp 0) instead of leaving them alone.
Like, all source distributions created by Poetry and uploaded to #PyPI now have 1970 timestamps that, simply speaking, break stuff. The most absurd thing is that ZIP can't handle that timestamp, so they override it and use another date for wheels 🤦.
-
New reason not to use #PythonPoetry just dropped: they reinvented "reproducible builds", poorly. The problem is, they missed the purpose of reproducible builds entirely and they use it for source distributions too, and when you don't use SOURCE_DATE_EPOCH, they force all files to epoch (as in timestamp 0) instead of leaving them alone.
Like, all source distributions created by Poetry and uploaded to #PyPI now have 1970 timestamps that, simply speaking, break stuff. The most absurd thing is that ZIP can't handle that timestamp, so they override it and use another date for wheels 🤦.
-
New reason not to use #PythonPoetry just dropped: they reinvented "reproducible builds", poorly. The problem is, they missed the purpose of reproducible builds entirely and they use it for source distributions too, and when you don't use SOURCE_DATE_EPOCH, they force all files to epoch (as in timestamp 0) instead of leaving them alone.
Like, all source distributions created by Poetry and uploaded to #PyPI now have 1970 timestamps that, simply speaking, break stuff. The most absurd thing is that ZIP can't handle that timestamp, so they override it and use another date for wheels 🤦.
-
New reason not to use #PythonPoetry just dropped: they reinvented "reproducible builds", poorly. The problem is, they missed the purpose of reproducible builds entirely and they use it for source distributions too, and when you don't use SOURCE_DATE_EPOCH, they force all files to epoch (as in timestamp 0) instead of leaving them alone.
Like, all source distributions created by Poetry and uploaded to #PyPI now have 1970 timestamps that, simply speaking, break stuff. The most absurd thing is that ZIP can't handle that timestamp, so they override it and use another date for wheels 🤦.
-
co jest gorsze niż #setuptools? Paczka, która przechodzi na #Hatchling, 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.
-
co jest gorsze niż #setuptools? Paczka, która przechodzi na #Hatchling, 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.
-
co jest gorsze niż #setuptools? Paczka, która przechodzi na #Hatchling, 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.