by markdog12 on 10/30/23, 10:51 AM with 89 comments
by Taikonerd on 10/30/23, 6:59 PM
I don't understand why the Python leadership hasn't shown stronger... leadership... in which tools they recommend.
by _dain_ on 10/30/23, 11:45 PM
That's what Python packaging feels like. At least videogames are fun.
by badrabbit on 10/31/23, 2:30 AM
Why not just improve upon pip? I don't know, just have pip use toml and give it different flags or auto detect things? Was a whole new ecosystem of tools needed?
I look at decisions like this and I know a Python 4.0 is on the way, just like the 2->3 jump because why not right?
Any language that updates it's syntax or toolset in a way that is impossible to have backwards compatibility is an irresponsible toy language, as awesome and powerful as it may be, the developers are still toying and tinkering with it with no regard to real world impact of their decisions.
Why can't python3.12 have a flag like --std=2.7.18 for example, like gcc? If the devs don't have enough resources, I would live to see a donate page I can help out with.
We are at a point where to deploy python you can't use python but you need shell scripts to figure out versions, venvs, pyev, pipx, poetry, etc... and reliably fail of course and every time you have to troubleshoot the problem. This is a failure in software engineering, new grads should be taught of python and similar languages and the lack of planning and organization and resulting cascading chaos as examples of how not to design the user experience of any piece of software.
Sorry if I exaggerated a bit anywhere, it's difficult to pretend all the frustrations and crying out "why???" when using python don't exist. But at the same time, it is still my #1 go to language for most use cases because the language itself is just fabulous!
by stabbles on 10/31/23, 9:41 AM
********************************************************************************
The license_file parameter is deprecated, use license_files instead.
By 2023-Oct-30, you need to update your project and remove deprecated calls
or your builds will no longer be supported.
********************************************************************************
by ahgamut on 10/31/23, 5:52 AM
I was sad to see setuptools officially deprecated, because it looks like another way in which Python packaging is being red-taped away for a non-expert. If someone like the OP (who has 10+ years programming Python) had to do so much for what appears to be a zstd CFFI/Rust wrapper, where does that leave the rest of us?
Here's a python package of mine that uses setup.py: https://github.com/ahgamut/cliquematch/blob/master/setup.py which I have not upgraded to the new tool(s) yet. I think I will need to upgrade it soon. If anyone has suggestions for a tool that will _fully replace_ setup.py, I would like to see tutorials with the following examples:
1. How would I build a package that has pure-Python files and data files? With setuptools I would use maybe MANIFEST.in or package_dir.
2. How would I build a package that has a CPython extension accessed via cffi? (this post points to the answer)
3. How would I build a package that has a CPython extension _without_ cffi, that just wraps some small C code I wrote with CPython's API? What about an extension that uses PyBind11? What about an extension that uses Rust?
4. How would I build a package that requires a "system" package like libblas-dev? Can something like numpy be built optimally without ever writing setup.py? What would a config for that look like? Last I remember numpy used their own patch of distutils to build, I wonder what it is now.
by fastasucan on 10/31/23, 10:48 AM
Having the mess of different blog posts and documentation sources saying different stuff is far from ideal though. If you can't sum up the process in a clear concise way you are far from done.
by mekoka on 10/31/23, 9:48 AM
Having said that, the author also sounds like he's ranting a bit. He seems to insist in finding specifically how to work the way setup.py used to, but without setup.py, instead of just learning how to use pyproject.toml. While learning the new way of doing something, how it replaces the old way is usually self-evident. The (official) tutorial he eventually lands on (https://packaging.python.org/en/latest/tutorials/packaging-p...) is actually a pretty good primer. Without previously knowing what hatchling, build, twine, or even pyproject.toml was, I was able to quickly understand their purpose. From clicking a few other links on the side bar, I understood that packaging is done with tools that present a frontend and interact with a backend. Sometimes a tooling set provides both. Hatch seems to be the frontend of one such project, while Hatchling is the backend.
by akubera on 10/31/23, 4:02 AM
One thing the author might want to try is writing their own "build-backend". You can specify your own script (even use setup.py) and that will be the target of python -m build or pip wheel or presumably whatever build-frontend you use.
# pyproject.toml
[build-system]
requires = ["setuptools"]
build-backend = "setup" # import setup.py as the build-module
backend-path = ["."]
def build_sdist(sdist_directory, config_settings):
...
def build_wheel(wheel_directory, config_settings, metadata_directory):
...
example:
$ python -m build --config-setting=foo=bar --config-setting=can-spam
# will call
>>> build_sdist("the/dist/dir", {"foo": "bar", "can": "spam"})
from setuptools.build_meta import build_sdist as setuptools_build_sdist
def build_sdist(sdist_directory, config_settings):
# ... code-gen and copy files to source ...
# this will call setup.py::setup, to make things extra confusing
return setuptools_build_sdist(sdist_directory, config_settings)
Still overall pretty fiddly/under-documented and a shame there seems to be a push for more dependencies rather than encouraging users to build their own solutions.
More info in PEP 517: https://peps.python.org/pep-0517/
by PennRobotics on 10/31/23, 7:37 AM
I open https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html
in my browser and see a 4,000+ word blog post.
Oof. Do I really want/need to read this?
-----
Kidding aside, good content and a great reminder to think before blindly upgrading—at least until the kinks and details are worked through
by wodenokoto on 10/31/23, 8:17 AM
I knew it was “the old” way, but didn’t realize it was abandoned.
Getting your code packaged seems way harder than developing your code.
by JodieBenitez on 10/31/23, 6:35 AM
I don't understand... Poetry solves this too.
by ri0t on 10/31/23, 10:42 AM
The blatant mess that ensued in the meantime (i.e. last few years) proves me right, imho.
by paradox242 on 11/1/23, 4:24 AM
I did not get halfway through this before I could start to feel the hairs of my neck start to stand on end. The numerous blind alleys. The promising leads that aren't. The official documentation that contains links to other documents that contradict the first and so I have to try and also piece together some temporal state to make any sense of any of it. Some days it seems I am actually some kind of an information archeologist, piecing together the detritus of overlapping civilizations.
by stop50 on 10/30/23, 1:43 PM
by Nimitz14 on 11/1/23, 5:20 PM
by anacrolix on 10/31/23, 6:55 AM
by __mharrison__ on 10/31/23, 2:41 AM
It seems like with a tenth of the effort of this blog rant the author could have written a flowchart or best practices.
Luckily for 99% of Python users, we only need to install libraries and not package them...