Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If this project is dead, just tell us

github.com

Post reply on HN
Print view View original

251–260 of 325 posts

Re: If this project is dead, just tell us

#251

Post by zer00eyz »

oblio wrote: post #159
hultner wrote: post #52

Earlier quoted context omitted.

As someone who's been in software development for two the better part of two decades now I would say that's far beyond the truth. Yes it's not great right now and it's not completely clear if I should recommend a new user pip+venv, pipenv, pyenv, poetry or conda and that's a big problem, Python was actually quite early to handle dependencies and packaging in a standardized and structured way. I remember that most of…

Maven basically solved Java's dependency problems back in 2005.

Serious question: Isn't maven the reason that you can't really package Hadoop? It is my (high level) understanding that it is at the core of (or a big part of) why Hadoop is so hard to build on your own vs VM.

Re: If this project is dead, just tell us

#252

Post by chenning »

marcus_holmes wrote: post #238
chenning wrote: post #231

Earlier quoted context omitted.

You know who else handled conflict in a way that wasn't always understood? Linus Torvalds. I think there's a theme here. Why is it that successful project maintainers sometimes lose their patience with the community? Remember when GvR left the Python community? I think one of his final public statements was, "Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people d…

Didn't Linus decide that he'd not been doing this well, and needed to change the way he managed conflict, though? Or did I dream that?

I thought he was apologizing for his use of personal attacks, profanity, insults, and generally what he describes as a lack of empathy. Things like that. His hardliner attitude hasn't changed.

Re: If this project is dead, just tell us

#253

Post by medmunds »

medmunds wrote: post #239
bluGill wrote: post #186

Earlier quoted context omitted.

Can you suggest something a little more concrete? What should I add to my project so that if I die tomorrow the project can continue without me? I work on a small project. I didn't add a CoC when the big push came about because I concluded that it was if I say it is bad it is bad, otherwise it is good - that is no CoC and so there is no point. (I did consider asking some large project - KDE for example - to be arbitr…

I’m in a similar situation, maintaining a project that’s used widely enough it should probably have a continuity plan, but not enough that it’s developed a robust community of other contributors who could step in. Jazzband [0] seems meant to address exactly this: “a collaborative community to share the responsibility of maintaining Python-based projects.” And it looked promising, but it’s not entirely clear that the…

Oh, just realized that pip-tools (being discussed favorably downthread as a pipenv alternative) is a Jazzband member project: https://github.com/jazzband/pip-tools.

Re: If this project is dead, just tell us

#254

Post by teddyh »

MadWombat wrote: post #246
gwd wrote: post #57

Earlier quoted context omitted.

C/C++'s package management story is "defer it to distributions". Personally I much prefer `apt-get install libfoo-dev` to 1) each language inventing its own incompatible system, and 2) each developer self-publishing, so there's little to no safety or accountability when adding a new dependency.

> Personally I much prefer `apt-get install libfoo-dev` So, what do you do when different projects need different versions of libfoo? Right, you download and build it locally inside the project tree and fiddle with makefiles to link to the local version rather than the one installed by apt-get. So basically you do your own dependency management. Good luck with that.

> So, what do you do when different projects need different versions of libfoo?

That’s an untenable situation. The package which depends on the older version of libfoo is either dead, in which case you should stop using it, or it will soon be updated to use the newer version of libfoo, in which case you’ll have to wait for a newer release. This is what release management is.

Re: If this project is dead, just tell us

#256

Post by kstrauser »

jimws wrote: post #100

What are the advantages of pipenv compared to plain pip and python3 -m venv/virtualenv? The latter works fine for me. What are good reasons to switch to pipenv?

The problem is that plain pip does not resolve incompatible dependencies. Pipenv (and better: Poetry) do. Here's an example:

You project depends on packages Spam and Eggs. Both of them depend on another package, Foo. The problem is, maybe that don't depend on the same version:

Spam 1 depends on Foo 2 or newer. Spam 2 depends on Foo major version 2, but it's known to be broken with Foo 3.

Eggs 1 depends on Foo 2 or newer. Eggs 2 requires some of the new features in Foo3.

If you run "pip install spam eggs", it will do something like this:

- Spam version 2 is the newest, so I'll install that.

- Spam 2 depends on Foo 2, so I'll also install Foo 2.

- Eggs 2 is the newest, so grab it!

- Oh no! Eggs 2 depends on Foo 3, but we've already installed Foo 2, so I'll warn you that I couldn't install Foo 3 and then keep on going.

Now you're in a state where "import eggs" will fail because its dependency on Foo 3 wasn't satisfied.

Suppose you use Pipenv (or better: Poetry) instead. It will do something like this:

- What's the newest version of Foo that can satisfy requirements for both Spam and Eggs?

- What's the newest version of Spam and Eggs that can use the version of Foo we identified in the previous step?

- Install Foo 2, Spam 2, and Eggs 1.

Now you have Eggs 1 instead of Eggs 2, but all the versions play nicely together. And if you say "but I really want Eggs 2!", it would give you an error message like "well, that requires Foo 3, but that means you'll have to roll back to Spam 1. Are you OK with that?" The point is that it figures all this stuff out for you and gives you the information to make smart decisions.

This is "dependency resolution". Poetry is great at it. Pipenv is decent at it. Pip doesn't do it at all. That's the real reason these tools are becoming popular.

Re: If this project is dead, just tell us

#257

Post by teddyh »

yjftsjthsd-h wrote: post #198
gwd wrote: post #57

Earlier quoted context omitted.

C/C++'s package management story is "defer it to distributions". Personally I much prefer `apt-get install libfoo-dev` to 1) each language inventing its own incompatible system, and 2) each developer self-publishing, so there's little to no safety or accountability when adding a new dependency.

So, to be clear, I also tend to prefer distro-supported packaging. However. Forcing everything to go through the distro means that you massively limit what's available by raising the barriers to entry, you slow pushing new versions (ranging from Arch's "as soon as a packager gets to it" to CentOS's "new major version will be available in 5 years"), and you lock yourself into each distro's packages and make portabilit…

> limit what's available by raising the barriers to entry

But that’s what you would have to do youself anyway. You can’t use all fresh upstream version of everything, since they don’t all work together. So some versions you’ll have to hold off on, some other versions might require minor patching. But this is exactly what distro maintainers do.

Re: If this project is dead, just tell us

#258

Post by gonational »

have_faith wrote: post #5

> I don't think you're bad people, but the least y'all can do is be honest I don't like this framing (sort of implies they aren't be honest) but regardless just switch if you're not happy with the release frequency and you have viable alternatives.

For me, and perhaps others, there is a desire to see this project explicitly move aside (vs slowly die), so that poetry and other projects can take the reins.

A lot of people say “just fork it” or “choose something else”, but the problem is that python is a finite community with a finite amount of energy, and a lot of this energy has been absorbed by the star power Kenneth acquired from his prior successes (namely, requests... which btw now has an even better replacement called httpx).

It’s almost like Kent needs to come out and say “I’m sorry I screwed up, here’s my towel; good night.”, so that people can move on.

Re: If this project is dead, just tell us

#259

Post by MadWombat »

teddyh wrote: post #254
MadWombat wrote: post #246

Earlier quoted context omitted.

> Personally I much prefer `apt-get install libfoo-dev` So, what do you do when different projects need different versions of libfoo? Right, you download and build it locally inside the project tree and fiddle with makefiles to link to the local version rather than the one installed by apt-get. So basically you do your own dependency management. Good luck with that.

> So, what do you do when different projects need different versions of libfoo? That’s an untenable situation. The package which depends on the older version of libfoo is either dead, in which case you should stop using it, or it will soon be updated to use the newer version of libfoo, in which case you’ll have to wait for a newer release. This is what release management is.

> The package which depends on the older version of libfoo is either dead, in which case you should stop using it, or it will soon be updated to use the newer version of libfoo

So you are suggesting that every time libfoo bumps its version I have to update the dependencies on all of my projects to use the latest, find and fix all the incompatibilities, test, release and deploy a new version? Seriously?

Post reply on HN