Earlier quoted context omitted.
> And no one is replying to this question. I'm a ghoOoOoOst!
The fading from the downvotes actually makes this comment amusing now. More so than before at least.
[deleted]
If this project is dead, just tell us
81–90 of 325 posts
Re: If this project is dead, just tell us
#82Earlier quoted context omitted.
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.
And it comes from a time, where a 2MB-webpage is considered acceptable. The whole idea of venvs is basically still considering some reuse. If you shout out loud "SCREW YOU LIBRARY REUSE", then npm is perfect of course...
Re: If this project is dead, just tell us
#83I’ve heard good things about pip-tools: https://github.com/jazzband/pip-tools
I recently switched from Poetry (to which I switched after pipenv) to pip-tools for some projects, because Poetry was not able to work properly with some dependencies.
Pip-tools has been a dream. It is just a thin layer of tools on top of Pip that separates your 'abstract' requirements (eg: djangoedit: it also automates updating the release requirements file (within the constraints of the abstract requirements).
Re: If this project is dead, just tell us
#84Earlier quoted context omitted.
pipenv does more than just create a venv, although it is my favorite tool for that. The most important thing it does is freeze the dependency tree using Pipfile.lock
> it does is freeze the dependency tree using Pipfile.lock sorry but what does freezing the dependency tree mean?
The idea is to make builds (more) reproducible. I can build a python program, test it thoroughly, and then be reasonably assured the whole thing won't come crashing down in CI/CD from a bad update to a transient dependency. Then when I want to update the libraries I know I'm doing it purposefully and can commit the new dependency tree to source control.
Re: If this project is dead, just tell us
#85Earlier quoted context omitted.
It looks like 1.4k people have forked it. The question is, which fork do I use? The problem is not that the source is unable to be updated, the problem is how to you organize peoples' efforts under a trusted maintainer long term? How do I know which forking effort to trust? My understanding is that that's kind of the point of groups like the "Python Packaging Authority". So if they're not going to merge pull requests…
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.
Re: If this project is dead, just tell us
#86669 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.
Indeed! It doesn't seem dead at all. While having a new release could be nice, I must also say I didn't face much trouble with the last release (I do Ansible work & use pipenv+pyenv to freeze the dependencies). I'm grateful to pipenv in how it has helped me here.
Re: If this project is dead, just tell us
#87Why 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
They don't do the same thing. pipenv allows you to create, manage virtual environments(using venv) apart from managing requirements file(Pipfile) and an npm like locking mechanism, dependency graphs, dev dependencies and more. I prefer poetry though, since the consensus seems to be coming together on pyproject.toml rather than individual files like Pipfile. A lot of tools have already started supporting the toml file…
I understand the value of a locking mechanism in the JS ecosystem because 1/ many packages depend on an intricate web of other packages that overlap, 2/ many packages use semver ranges, and 3/ you don't want two versions of the same package running on a user's browser, due to conflicts and increased size.
I can't think of many Python packages that have the same issues, and Python code isn't sent to and running on a user's browser.
Am I wrong or is there a reason that a locking mechanism (other than git) is helpful in Python?
Re: If this project is dead, just tell us
#88virtualenv 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?
Re: If this project is dead, just tell us
#89This is all MIT licensed, if people care so much, why has nobody forked this? Why are people talking about jumping ship to a completely different project instead of forking and cutting a new release from there?
There's 1400 forks. I'm sure that people will move to one of them if the original is pronounced dead.
The question is who will have access to make new releases on the Python Package Index. Otherwise, they'd have to find a new name for their fork.
Re: If this project is dead, just tell us
#90This is all MIT licensed, if people care so much, why has nobody forked this? Why are people talking about jumping ship to a completely different project instead of forking and cutting a new release from there?
There's 1400 forks. I'm sure that people will move to one of them if the original is pronounced dead.
That normally means there have been 1.4k pull requests not 1.4k people actively maintaining forks.