eager_eagle@lemmy.world
on 06 Apr 2025 16:28
collapse
nah, the main reason we have 15 standards was the lack of an official one. This is good.
taaz@biglemmowski.win
on 06 Apr 2025 07:36
nextcollapse
Oh finally.
The news on this is mixed. “All the tool authors have signaled they can and would implement the PEP as an export format,” said Cannon, but that does not mean they would adopt it as their sole lock file format. The creator of uv, Charlie Marsh, said that “today, the PEP 751-style pylock.toml files are not sufficient to replace uv.lock,” but that support will be added for export.
This sounds little better then “here is 13th standard” even though it’s not feature full.
logging_strict@programming.dev
on 07 Apr 2025 03:59
nextcollapse
Viva la package dependencies!
Does it do away with setuptools? After my experience interacting with the maintainers, now refer to that package as, The Deep State
The Deep State only supports loading dependencies from pypi.org
Which has many advantages right up until it doesn’t.
This new standard contains dependency host url. Hope there is a package other than setuptools that supports it.
When bring it up, and prove it, the responses alternate between playing dumb and gaslighting. The truth is The Deep State are gate keepers. And they are in the way.
Training wheels off mode please! So there is support for requirements files that contain on which server dependencies are hosted with more than one choice. Would like the option to host packages locally or remotely using pypiserver or equivalent.
On the positive side, setuptool maintainers did not suggest voodoo dolls, try to wait out the planetary alignment, better economic conditions, or peace on Earth.
That’s how the conversation comes off to my eyes. But form your own opinion. Especially enjoyable for folks who also enjoyed the TV series, The Office.
What are the alternatives to being stonewalled by setuptools?
Disclosure: Wrote requirements rendering package, wreck. I have my own voodoo dolls and plenty of pins
eager_eagle@lemmy.world
on 07 Apr 2025 05:29
nextcollapse
I don’t know why people are still bothering with setuptools for new projects.
logging_strict@programming.dev
on 07 Apr 2025 23:56
nextcollapse
Will look at it again
logging_strict@programming.dev
on 08 Apr 2025 00:25
collapse
From the hatch docs, not seeing where it discusses publishing to alternative package warehouses.
eager_eagle@lemmy.world
on 08 Apr 2025 01:01
collapse
AFAIK setuptools and hatch are for building. Publishing is a different process. You can try uv for publishing, but idk if it supports publishing to alternatives to PyPI.
logging_strict@programming.dev
on 10 Apr 2025 06:22
collapse
setuptools is for enforcing a cartel, naively can simplify that to for building.
I hope uv completely replaces setuptools and build. Then the maintainers can move on to another racket.
abruptly8951@lemmy.world
on 07 Apr 2025 06:13
nextcollapse
logging_strict@programming.dev
on 10 Apr 2025 05:46
collapse
git sources are not allowed by pypi.org
pypi.org cartel does not like competition; github repos are no exception.
Try to publish packages with git sourced packages and find out the hard way or save time and take my word for it.
– author of wreck
Randelung@lemmy.world
on 08 Apr 2025 00:55
nextcollapse
How is this different from regular dependencies?
logging_strict@programming.dev
on 10 Apr 2025 06:06
collapse
Regular dependencies lack host url and hashes. Those are most important.
For the full details, encourage you to read pep751
^^ look a link! Oh so clickable and tempting. Go ahead. You know that pretty blue font-color is just asking for it. And after clicking the font-color changes colors. Wonder what font-color it’ll become? Hmmmm
TunaLobster@lemmy.world
on 08 Apr 2025 01:44
nextcollapse
Here I am still using requirements.txt and the built in venv. Sure poetry looks cool. I just don’t have it everywhere. Now I just have to wait 5 years before I can reliably use a pylock.toml. Progress!
logging_strict@programming.dev
on 10 Apr 2025 05:39
collapse
i love requirements files, venv, and pyenv.
Bringing requirements into pyproject.toml does not have enough value add to bother with. My requirements files are hierarchical. Extensively using -r and -c options AND venv aware.
pep751 does bring value, by stating both the host url and the hash of every package.
setuptools will fight this to continue their strange hold on Python
logging_strict@programming.dev
on 10 Apr 2025 05:29
collapse
i’m sad to report
wreck 0.3.4.post0 no longer emits build front end options into .lock files wreck#30.
Background of efforts to beg and plead for setuptools maintainers to bend ever so slightly.
Continuing from denied way to pass build front end options thru requirement files so know non-pypi.org hosts
setuptools#4928
This hurts those hosting packages locally or remotely on non-pypi.org package index servers. For those who are, the packages themselves give no clue where the dependencies and transitive packages are hosted.
Each and every user would need to have a ~/.pip/pip.conf or pass –extra-index-url pip install cli option. And somehow know all the possible package index servers.
This allows the pypi.org cartel to continue along it’s merry way unimpeded.
Wish pep751 good luck and may there be a .unlock equivalent. Do not yet understand how the pep751 implementers will bypass setuptools and build.
threaded - newest
xkcd.com/927/
nah, the main reason we have 15 standards was the lack of an official one. This is good.
Oh finally.
This sounds little better then “here is 13th standard” even though it’s not feature full.
Viva la package dependencies!
Does it do away with setuptools? After my experience interacting with the maintainers, now refer to that package as, The Deep State
The Deep State only supports loading dependencies from pypi.org Which has many advantages right up until it doesn’t.
This new standard contains dependency host url. Hope there is a package other than setuptools that supports it.
When bring it up, and prove it, the responses alternate between playing dumb and gaslighting. The truth is The Deep State are gate keepers. And they are in the way.
Training wheels off mode please! So there is support for requirements files that contain on which server dependencies are hosted with more than one choice. Would like the option to host packages locally or remotely using pypiserver or equivalent.
On the positive side, setuptool maintainers did not suggest voodoo dolls, try to wait out the planetary alignment, better economic conditions, or peace on Earth.
That’s how the conversation comes off to my eyes. But form your own opinion. Especially enjoyable for folks who also enjoyed the TV series, The Office.
What are the alternatives to being stonewalled by setuptools?
Disclosure: Wrote requirements rendering package, wreck. I have my own voodoo dolls and plenty of pins
Have you tried hatch?
I don’t know why people are still bothering with setuptools for new projects.
Will look at it again
From the hatch docs, not seeing where it discusses publishing to alternative package warehouses.
AFAIK setuptools and hatch are for building. Publishing is a different process. You can try
uvfor publishing, but idk if it supports publishing to alternatives to PyPI.setuptools is for enforcing a cartel, naively can simplify that to
for building.I hope uv completely replaces setuptools and build. Then the maintainers can move on to another racket.
Poetry or UV
Still haven’t tried the latter but heard good things
I really don’t understand what you are complaining about. There has been a “training wheels off I want to do things manually” option for ages.
stackoverflow.com/…/how-to-state-in-requirements-…
git sources are not allowed by pypi.org
pypi.org cartel does not like competition; github repos are no exception.
Try to publish packages with git sourced packages and find out the hard way or save time and take my word for it.
– author of wreckHow is this different from regular dependencies?
Regular dependencies lack host url and hashes. Those are most important.
For the full details, encourage you to read pep751
^^ look a link! Oh so clickable and tempting. Go ahead. You know that pretty blue font-color is just asking for it. And after clicking the font-color changes colors. Wonder what font-color it’ll become? Hmmmm
Python EEE incoming!!!
Here I am still using requirements.txt and the built in venv. Sure poetry looks cool. I just don’t have it everywhere. Now I just have to wait 5 years before I can reliably use a pylock.toml. Progress!
i love requirements files, venv, and pyenv.
Bringing requirements into
pyproject.tomldoes not have enough value add to bother with. My requirements files are hierarchical. Extensively using-rand-coptions AND venv aware.pep751 does bring value, by stating both the host url and the hash of every package.
setuptools will fight this to continue their strange hold on Python
i’m sad to report
wreck 0.3.4.post0 no longer emits build front end options into
.lockfiles wreck#30.Background of efforts to beg and plead for setuptools maintainers to bend ever so slightly.
Continuing from denied way to pass build front end options thru requirement files so know non-pypi.org hosts setuptools#4928
This hurts those hosting packages locally or remotely on non-pypi.org package index servers. For those who are, the packages themselves give no clue where the dependencies and transitive packages are hosted.
Each and every user would need to have a
~/.pip/pip.confor pass–extra-index-urlpip install cli option. And somehow know all the possible package index servers.This allows the pypi.org cartel to continue along it’s merry way unimpeded.
Wish pep751 good luck and may there be a
.unlockequivalent. Do not yet understand how the pep751 implementers will bypass setuptools and build.