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

101–110 of 325 posts

Re: If this project is dead, just tell us

#101

Post by joshstrange »

YPCrumble wrote: post #87
sidmitra wrote: post #10

Earlier quoted context omitted.

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 u…

I think this has less to do with "you don't want two versions of the same package running on a user's browser" and more to do with "when I clone a project and run npm/pip install I want it to be in a known state".

I don't use Python/pip much but as for npm: the problem is when your dependencies, direct or indirect (dependencies of dependencies), aren't "exact". You have something like "~1.2.3" or "^1.2.3". If every developer followed Semvar perfectly, never shipped regressions or new bugs when fixing a bug, and was always able to identify every breaking change then life would be perfect.

That is, however, not the world we live in. So a "lock" file respects your "fuzzy" versions ^/~ when you first run the npm install and then subsequent runs will install using the exact versions you downloaded the first time. This helps solve the "works me me"/"work on my machine" problems. The idea being if you can run it locally then the build server and production can also build/run your code.

Re: If this project is dead, just tell us

#102

Post by aequitas »

yingw787 wrote: post #92
aequitas wrote: post #83

Earlier quoted context omitted.

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: django edit: it also automates updating the release requirements file (within the constraints of the abstract requirements).

I’ve heard good things wrt determinism and packaging for different environments (dev/test/prod) on top of the simplicity!

Have a look at https://github.com/jazzband/pip-tools#workflow-for-layered-r... Both the 'input' and 'output' requirements are pip compatible files (just with different extensions). It uses pip features like '-c' to include other contraints in your requirements.

For me, if they would merge Pip-tools into Pip and call it a day, my package management issues for Python are solved.

Re: If this project is dead, just tell us

#103

Post by tsukurimashou »

theamk wrote: post #37
tsukurimashou wrote: post #22

> I'm not mad, I don't think you're bad people, but the least y'all can do is be honest with us how entitled can someone be, you have the source code, if you're not happy why not contributing yourself? It is like some people don't realize most of these projects are other people working for free on their free time and giving that for free to anyone that feels like using it

Because only one person can make a release. That’s exactly the complaint: people have been contributing, a lot.. but the maintainer won’t release the contribution. How would you feel if your fixed the bug patch more than two years ago, your PR was accepted.. but users still do not have the fix?

I wouldn't feel a thing, I would release the patch on my own fork and people would be free to merge my patch to their own fork or use mine as a base. It requires more work sure, but how would you solve that problem? People have their life, they can work hard on some project then drop it and never touch it again. You cannot force people willingly giving their time away for other people to do it all their life.

Re: If this project is dead, just tell us

#104

Post by kennydude »

WilliamEdward wrote: post #65
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'?

Not everyone uses the same 3 commands which means for a new python dev, finding out about venvs isn't as immediately obvious as it should be. Even then it's shooved (sadly) as an optional thing

Re: If this project is dead, just tell us

#105

Post by xenator »

Pipenv is very controversial project who lost its reputation. Many times I have issues that was making my everyday life very uncomfortable. And of course I saw issues on GitHub with other people who also have the same problems. And then in the middle of the very constructive conversation somebody from the maintainers team or initial creator of the project jumping to the thread and very aggressively close it or saying something like "go f--k yourself we don't need it". Srsly? Who will like this level of the conversation? It is ok if you don't have resources or time or whatever, but we have this particular problem. Don't be rude and push people against you.

My personal opinion that some day ripples on the water made whole loop.

And last but not least: pip+requrements.txt are not the best, but pipenv doesn't add much over it. It gives you a little but introduce another level of abstraction over the same things with its own level of complexity.

Re: If this project is dead, just tell us

#106

Post by cure »

hultner wrote: post #52
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.

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…

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

As someone who has had to deal with Python's packaging a lot, I would say that it's really, really bad. Maybe not the worst in the world, but it is much closer to the worst than to the best.

There are 15 ways to package Python modules, none of which are feature complete (but a lot of them pretend to be). Every year or so someone decides that they need to write another packaging tool for Python, and then they give up before it is feature complete.

A tool like virtualenv is useful, but it overpromises and underdelivers (this is the overarching theme of Python packaging imo): it does not completely separate your environment from the system. E.g. virtualenv still uses the host system python packages cache, and it does something rather nasty with .so's that get copied from the host system...

And don't get me started on dependency management in Python. When the dependencies of your dependencies make breaking interface changes, you're in for a world of pain.

I find it amusing, in a sad way, that the language that prides itself on "there is one way to do it" screwed up so badly in the packaging department by not having one good way to do it. Meanwhile the language whose motto is "there is more than one way to do it" has a standard, sane way to package things, with multiple tools that work together in a coherent way. Perl got this one right.

Re: If this project is dead, just tell us

#107

Post by linuxftw »

josteink wrote: post #49
Tajnymag wrote: post #32

Earlier quoted context omitted.

Well, C/C++ dependencies are also a hell to reliably setup on different platforms.

But C/C++ is messy because it doesn’t have a language/platform-provided package-management system, while python actually does. So that’s apples to no oranges, I guess. And it still doesn’t leave python looking particularly good.

I would consider the packages shipped by most distros as platform-provided package-management. It's not specific to C/C++, but if I'm developing something for say, Debian, I'm going to use as many system-provided libs as possible.

Re: If this project is dead, just tell us

#108

Post by reledi »

I’m really curious how places with heavy Python usage solve the dependency tree, packaging, distribution, release problems.

I’m always lost about what the best practice is when I occasionally need to write Python. I just wish there was one way to do it all.

Re: If this project is dead, just tell us

#109

Post by coleifer »

I see a lot of comments about "hey it's open-source, just fork". The reason people feel upset is because this project was shilled hard when it was released. The python packaging team was officially recommending it, stuff like that. There was some backlash because of legitimate usability concerns with the software, and what was perceived as the tacit blessing of a project solely due to the maintainer's having written another popular project.
Post reply on HN