Live data from Hacker News

Pypi.org is running a survey on the state of Python packaging

pypi.org

71–80 of 193 posts

Re: Pypi.org is running a survey on the state of Python packaging

#71
post #66
post #51

I just wish they'd change their name so that my students stop snickering. (The name is pronounced like the French word for "piss".)

Isn't PyPI pronounced like: pie (food/π) + pea + eye (). that is different from the french "pipi": pea + pea.

Yep: https://pypi.org/help/#pronunciation

Re: Pypi.org is running a survey on the state of Python packaging

#72
post #41

For improvements I commented: Remove setup.py files and mandate wheels. This is the root cause of a lot of the evil in the ecosystem. Next on the list would be pypi namespaces, but there are good reasons why that is very hard. The mission statement they are proposing, “a packaging ecosystem for all”, completely misses the mark. How about a “packaging ecosystem that works” first? I spent a bunch of time recently fixin…

> The mission statement they are proposing, “a packaging ecosystem for all”, completely misses the mark. How about a “packaging ecosystem that works” first?

I think at the point a programming language is going on about "mission statements" for a packaging tool, you know they've lost the plot

copy Maven from 2004 (possibly with less XML)

that's it, problem solved

Re: Pypi.org is running a survey on the state of Python packaging

#73
post #70
post #41

For improvements I commented: Remove setup.py files and mandate wheels. This is the root cause of a lot of the evil in the ecosystem. Next on the list would be pypi namespaces, but there are good reasons why that is very hard. The mission statement they are proposing, “a packaging ecosystem for all”, completely misses the mark. How about a “packaging ecosystem that works” first? I spent a bunch of time recently fixin…

> For improvements I commented: Remove setup.py files and mandate wheels. This would make most C extensions impossible to install on anything other than x86_64-pc-linux-gnu (or arm-linux-gnueabihf/aarch64-linux-gnu if you are lucky) because developers don't want to bother building wheels for them.

I think it'd make other things impossible too. One project I help maintain is C++ and is mainly so. It optionally has Python bindings. It also has something like 150 options to the build that affect things. There is zero chance of me ever attempting to make `setup.py` any kind of sensible "entry point" to the build. Instead, the build detects "oh, you want a wheel" and generates `setup.py` to just grab what the C++ build then drops into a place where `build_ext` or whatever expects them to be using some fun globs. It also fills in "features" or whatever the post-name `[name]` stuff is called so you can do some kind of post-build "ok, it has a feature I need" inspection.

Re: Pypi.org is running a survey on the state of Python packaging

#74
post #64
post #15

I just wish that PyPI would enforce binary wheels going forward (at least for linux x64/arm64 for people who use Docker, but ideally for all common platforms). They already supply the cibuildwheel tool to automate their builds, so it shouldn't be that hard for library developers... Software developers shouldn't need to figure out what build-time dependencies their libraries need...

Should PyPI kick my project off because it don't support MS Windows? My package uses C and Cython extensions. While I support macOS and Linux-based OSes, I don't know how to develop on or support MS Windows. I've tried to be careful about the ILP32 vs LP64 differences, but I suspect there's going to be many places where I missed up. I also use "/dev/stdin" to work-around my use of a third-party library that has no wa…

Can't you use "CON" instead of "/dev/stdin" on Windows?

Re: Pypi.org is running a survey on the state of Python packaging

#75
post #17

My wishlist: We need a way to configure an ordered list of indexes pip searches for packages. —extra-index-url or using a proxy index is not the solution. Also namespaces and not based on a domain. So for example: pip install apache:parquet Also some logic either in the pip client or index server to minimize typosquatting Also pip should adopt a lock file similar to npm/yarn. Instead of requirements.txt And also “pip…

> apache:parquet

How are you going to name the file storing the wheel for that package? Using ":" on Windows is going to be problematic.

Re: Pypi.org is running a survey on the state of Python packaging

#76
post #41

For improvements I commented: Remove setup.py files and mandate wheels. This is the root cause of a lot of the evil in the ecosystem. Next on the list would be pypi namespaces, but there are good reasons why that is very hard. The mission statement they are proposing, “a packaging ecosystem for all”, completely misses the mark. How about a “packaging ecosystem that works” first? I spent a bunch of time recently fixin…

Setup.py can do things wheels can't. Most notably it's the only installation method that can invoke 2to3 at runtime without requiring a dev to create multiple packages.

Re: Pypi.org is running a survey on the state of Python packaging

#77
State of the art python packaging must include support for common use cases such as conda+machine learning.

It’s incredible how even Julia’s Pkg.jl supports better python packaging in combination with conda than the official python packaging tools.

This is very clearly a question of the culture of the core python developers (such as brett cannon) who seem to think the machine learning people with their compilers and JITs are not an important part of the community.

Re: Pypi.org is running a survey on the state of Python packaging

#78
post #66
post #51

I just wish they'd change their name so that my students stop snickering. (The name is pronounced like the French word for "piss".)

Isn't PyPI pronounced like: pie (food/π) + pea + eye (). that is different from the french "pipi": pea + pea.

Sure. Now tell that to a bunch of immature college juniors. If you read the letters "pypi" in French, it sounds exactly like "pipi".

And wait until you learn what "bit" sounds like in French.

Re: Pypi.org is running a survey on the state of Python packaging

#79
post #41

For improvements I commented: Remove setup.py files and mandate wheels. This is the root cause of a lot of the evil in the ecosystem. Next on the list would be pypi namespaces, but there are good reasons why that is very hard. The mission statement they are proposing, “a packaging ecosystem for all”, completely misses the mark. How about a “packaging ecosystem that works” first? I spent a bunch of time recently fixin…

Setup.py can do things wheels can't. Most notably it's the only installation method that can invoke 2to3 at runtime without requiring a dev to create multiple packages.

It’s lucky Python 2 isn’t supported anymore then, and everyone has had like a decade to run 2to3 once and publish a package for Python 3, so that use case becomes meaningless.

Re: Pypi.org is running a survey on the state of Python packaging

#80
post #79

Earlier quoted context omitted.

Setup.py can do things wheels can't. Most notably it's the only installation method that can invoke 2to3 at runtime without requiring a dev to create multiple packages.

It’s lucky Python 2 isn’t supported anymore then, and everyone has had like a decade to run 2to3 once and publish a package for Python 3, so that use case becomes meaningless.

You'd be surprised at how many billions lines of production code are still at 2 (and could not care less whether it's end-of-lined)
Post reply on HN