Live data from Hacker News

If this project is dead, just tell us

github.com

121–130 of 325 posts

Re: If this project is dead, just tell us

#121
post #56

Earlier quoted context omitted.

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.

pip freeze gets everything installed.

Yes, that 'freezes' everything installed... but that's the point. If you want to update a direct dependency, you just do pip install -u . Any indirect dependencies are updated, and you freeze again.

Sometimes direct-dependency-a and direct-dependency-b have a conflict on which version of indirect-dependency-y you need. This is what we call doing 'actual work.'

Re: If this project is dead, just tell us

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

Determining if a project is alive or dead really is a problem. And this problem will grow from year to year.

There are so many small and medium sized projects on Github, where you have no idea if they are maintained or not. Sometimes there are projects which are alive and kicking with multiple pull requests, maintainers promising changes or a major release and suddenly nothing. Sometimes smaller projects see no changes for months, but they simply work and don't need maintenance at all. Maybe the community moved elsewhere and and the project will only see bugfixes coming in and no more features?

The burden of figuring this all out lies with the visitor and is a annoying hassle.

I would love if Github could somehow show me on the landing page, if the project is worth investing time in. Maybe they could send a heartbeat to the maintainer and simply show the project as dead as soon as there is no response?

Re: If this project is dead, just tell us

#124

Earlier quoted context omitted.

Alternatively, they could add one of those 1.4k people in to help if they seem to have produced working code for the project prior.

Github forks are meaningless. Sometimes they're forked because people think it's the same as the "star" button. Sometimes it's to have a classy project show up on your profile. Sometimes it's because you want to submit a PR. Sometimes it's because your company requires a software but isn't willing to use the public mainline.

Doesn't mean that at least one of those people doesn't actually maintain their forks and do PRs to the project.

Re: If this project is dead, just tell us

#125

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?

The faults aren't so much with the actual NPM software as with the whole ecosystem. The real root of the problem IMO is that Javascript has such a tiny std lib compared to other popular languages that have package management systems. This encourages lots of people who are missing various functions normally found in std libs to write packages implementing various combinations of those functions. Those who are writing larger packages then depend on various combinations of those little helper packages. So of course, if you need to use multiple large packages to do something useful, they'll tend to pull in a huge forest of tiny packages in a bunch of versions.

Re: If this project is dead, just tell us

#126
post #88

virtualenv venv —-python=python3.7 touch requirements.txt echo "flask" > requirements.txt source venv/bin/activate pip install -r requirements.txt Done, what’s so difficult about that?

Also:

pip freeze > prod.txt

And then on production environment:

pip install -r prod.txt

Re: If this project is dead, just tell us

#127
post #25

Meanwhile, Poetry just announced 1.0: https://python-poetry.org/blog/announcing-poetry-1-0-0.html

The 1.0 release is a must for a working poetry environment. The people handling it are friendly and communicate over github and discord. However, it's not all roses. - VSCode supports poetry as a second class citizen - Documentation is there, but only in github issues - There is no migration path from pip and pipenv to poetry - I can't do releases via CI because of a poetry bug.

[deleted]

Re: If this project is dead, just tell us

#128

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?

[deleted]

Re: If this project is dead, just tell us

#129
post #96
post #67

Earlier quoted context omitted.

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

a bit like "pip freeze > requirements.txt" then?

> a bit like "pip freeze > requirements.txt" then?

With the added bonus that it also contains a hash of the package so if someone pushes a new version with the same version number it would complain that the hashes don't match.

Re: If this project is dead, just tell us

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

Determining if a project is alive or dead really is a problem. And this problem will grow from year to year. There are so many small and medium sized projects on Github, where you have no idea if they are maintained or not. Sometimes there are projects which are alive and kicking with multiple pull requests, maintainers promising changes or a major release and suddenly nothing. Sometimes smaller projects see no chang…

> Maybe they could send a heartbeat to the maintainer and simply show the project as dead as soon as there is no response?

If I could not automate response to that, I'd ignore it.

My employer gets to make bullshit intrusions on my time like that, no way will I waste my life on make-work from Github.

Post reply on HN