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

61–70 of 325 posts

Re: If this project is dead, just tell us

#61

Post by josteink »

madeofpalk wrote: post #53
josteink wrote: post #24

Earlier quoted context omitted.

> Python packaging in general is such a messy ecosystem Not just messy. It’s probably worst in class. I at least can’t come up with a single worse package-management story which I do know of. Edit: I’m talking about platforms with actual package-management which sucks, not platforms with the absence of package-management all together.

I thought NPM was everyone's favourite hated package manager/repository?

It clearly has its faults, but it is simple to use, requires no “venvs”, is CI-friendly and mostly does what it’s supposed to with few surprises.

Much unlike how things work with python.

Re: If this project is dead, just tell us

#62

Post by jedieaston »

fiatjaf wrote: post #20

If there are no commits, maybe that means it is finished, stable, reliable? I would like more projects to be without commits and just work. I don't understand why there must always be new commits if everything already works.

Pipenv isn't stable and reliable yet though, at least compared to pip+venv. The tooling is really handy and it makes it in theory easier to write Python code, but in practice there is still work to be done.

Re: If this project is dead, just tell us

#63

Post by rthomas6 »

gwd wrote: post #57
rthomas6 wrote: post #31

Earlier quoted context omitted.

C/C++.

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.

That's a fair point. I live in embedded world most of the time, and using third party libraries in that space is not always so easy :)

Re: If this project is dead, just tell us

#64

Post by kawsper »

fiatjaf wrote: post #20

If there are no commits, maybe that means it is finished, stable, reliable? I would like more projects to be without commits and just work. I don't understand why there must always be new commits if everything already works.

There are commits, but no release, it's very frustrating if you depend on any of those commits, and there are no one available to cut a new version, or to pass on the torch.

For four years there was commits to the beanstalkd project, but no release, it took about a year after the issue was first raised until someone appeared and a maintainer was found: https://github.com/beanstalkd/beanstalkd/issues/399

Re: If this project is dead, just tell us

#65

Post by WilliamEdward »

mikkelam wrote: post #8

Pipenv has spawned so much controvery.. One big shitfest. Python packaging in general is such a messy ecosystem

Just curious, you don't find learning entire languages hard or confusing but suddenly writing 3 commands to set up a venv is too 'messy'?

Re: If this project is dead, just tell us

#66

Post by shakna »

petters wrote: post #30
casion wrote: post #18

669 commits in the last year... and asking if the project is dead? I'm a bit confused here. Maybe the project is mismanaged, or there's some upstream issue with package distro, but it seems to be far from dead.

It may be abandoned by everyone with release permissions.

Most of the 2018 release were by techalchemy, who made commits in July.

Right now, it seems like the issues raised in [0] are still a problem. The release pipeline has problems, and dragging through that isn't a priority.

[0] https://github.com/pypa/pipenv/issues/3742

Re: If this project is dead, just tell us

#67

Post by fhennig »

Redoubts wrote: post #47
blondin wrote: post #19

Earlier quoted context omitted.

> it does is freeze the dependency tree using Pipfile.lock sorry but what does freezing the dependency tree mean?

probably recording exact dependency versions, based on a loose requirements.txt and when it was built. You may want this because you have a library that you shouldn't be pinning to the third decimal on a sem-ver package, but that you don't want to hiccup in CI due to a dot-release. Or maybe you think a loose file your tooling can read, and a hyper-specific file your builder should read, is a better interface for a pr…

Yes, kind of like that. Except that it doesn't use requirements.txt but rather a file called Pipfile. In there you can also pin version, or leave them unspecified or only partially specified and you can also divide them in dev-packages and normal packages (so it allows for a bit more flexibility than a requirements.txt file).

Re: If this project is dead, just tell us

#69

Post by Scarblac »

guggle wrote: post #56
css wrote: post #3

Why would someone choose to use a third party library when the first party solution[0] is more than adequate in the first place? [0] https://docs.python.org/3/library/venv.html

I don't get it either... nor do I understand why venv is considered difficult to use. "It automatically creates and manages a virtualenv for your projects, as well as adds/removes packages from your Pipfile as you install/uninstall packages." Well, thanks but automate "python -m venv myvenv" ? Add/remove packages from a "Pipfile" ? Do I have to specify dependencies somwhere else than requirements.txt ? Why ? There mu…

It's about dependencies of dependencies.

Requirements.txt only lists versions of your project's requirements, but Pip actually automatically installs dependencies of those requirements too. And those versions aren't listed in your requirements.txt.

https://realpython.com/pipenv-guide/#dependency-management-w... -- This page about Pipenv vs pip + virtualenv goes into more detail.

Re: If this project is dead, just tell us

#70

Post by chaosfox »

fiatjaf wrote: post #20

If there are no commits, maybe that means it is finished, stable, reliable? I would like more projects to be without commits and just work. I don't understand why there must always be new commits if everything already works.

there are almost 700 commits to master since the latest release.
Post reply on HN