Live data from Hacker News

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

pypi.org

11–20 of 193 posts

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

#11
I have a terrible admission to make: one of the reason I like Python is its huge standard library, and I like that because I just ... despise looking for libraries, trying to install them, evaluating their fitness, and so on.

I view dependencies outside of the standard library as a kind of technical debt, not because I suffer from Not Invented Here and want to code it myself, no, I look and think, "Why isn't this in the standard library with a working set of idioms around it?"

I haven't developed anything with more than five digits of code to it, which is fine for me, but part of it is just ... avoidance of having to screw with libraries. Ran into a pip issue I won't go into (it requires a lot of justification to see how I got there) and just ... slumped over.

This has been a bad spot in Python for a long, long time. While people are busy cramming their favorite feature from their last language into Python, this sort of thing has languished.

Sadly, I have nothing to offer but encouragement, I don't know the complexities of packaging, it seems like a huge topic that perhaps nobody really dreamed Python would have to seriously deal with twenty years ago.

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

#12

I wish there is some package manager in middle of conda and pip. Conda is too strict and often get stuck in SAT solving. pip doesn't even ask when reinstalling a version currently being used. Edit: Typo: reinstalling a version of package currently being used

we find mamba solves deps solving for conda (we fail to do GPU dependencies without it), and I think it's getting integrated

my main thing w/ conda is it's bananas figuring out how to make a new recipe, which is pretty surprising

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

#13

I wish there is some package manager in middle of conda and pip. Conda is too strict and often get stuck in SAT solving. pip doesn't even ask when reinstalling a version currently being used. Edit: Typo: reinstalling a version of package currently being used

Try poetry. It wraps pip and fixes a lot of its issues

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

#14

I wish there is some package manager in middle of conda and pip. Conda is too strict and often get stuck in SAT solving. pip doesn't even ask when reinstalling a version currently being used. Edit: Typo: reinstalling a version of package currently being used

Try using mamba (https://github.com/mamba-org/mamba)

We ran into many unsolvable or 30m+ solvable envs with conda that mamba handled quickly.

The underlying solver can be used with conda directly as well, but I have not done that (https://www.anaconda.com/blog/a-faster-conda-for-a-growing-c...)

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

#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...

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

#16
post #3

The survey is at https://www.surveymonkey.co.uk/r/M5XKQCT .

Seems more oriented to (potential) contributors than end users of the packaging system. Who cares about mission statements and inclusivity, secure funding and pay developers to make the tools.

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

#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 list” should output a dependency tree like “npm list”

I should not have to compile source when I install. Every package should have wheels available for the most common arch+OS combos.

Also we need a way to download only what you need. Why does installing scipy or numpy install more dependencies than the conda version? For example pywin and scipy.

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

#18

I have a terrible admission to make: one of the reason I like Python is its huge standard library, and I like that because I just ... despise looking for libraries, trying to install them, evaluating their fitness, and so on. I view dependencies outside of the standard library as a kind of technical debt, not because I suffer from Not Invented Here and want to code it myself, no, I look and think, "Why isn't this in…

More packages in the standard library means it can run in less machines and more extra junk needs to be installed.

Minimal standard library languages let you pick and choose what needs to be run. Golang is a nice happy medium since it’s compiled.

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

#19

I have a terrible admission to make: one of the reason I like Python is its huge standard library, and I like that because I just ... despise looking for libraries, trying to install them, evaluating their fitness, and so on. I view dependencies outside of the standard library as a kind of technical debt, not because I suffer from Not Invented Here and want to code it myself, no, I look and think, "Why isn't this in…

> despise looking for libraries, trying to install them, evaluating their fitness, and so on.

This is exactly why I prefer the larger opinionated web frameworks (Django, Vue.js) to the smaller more composable frameworks (Flask, React). I don’t what to make decisions every time I need a new feature, I want something that “just works”.

Python and Django just work, and brilliantly at that!

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

#20
post #2

I imagine many of you have feedback that could be useful to folks making decisions about the future of Python packaging, a common subject of complaint in many discussions here. Remember not to just complain, but to offer specific problems/solutions--i.e. avoid statements like "virtualenvs suck, why can't it be like NPM?" and prefer instead feedback like "the difference between Python interpreter version and what virt…

"virtualenvs suck, why can't it be like NPM?" is a specific problem and a specific solution. The problem being having to manage venvs (which have many gotchas and pitfalls, and no standarization), and the solution is to replace those with packages being installed into the project folder with standardized and well-known tools.
Post reply on HN