If this project is dead, just tell us • Hacker News Board

Re: If this project is dead, just tell us

#111

Post by perlgeek » Fri, Dec 13, 2019, 2:51 PM UTC

Scarblac wrote: post #69

guggle wrote: 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.

You can just 'pip freeze > requirements.txt'

Boom, all recursive dependencies frozen to their current state.

Re: If this project is dead, just tell us

#112

Post by Scarblac » Fri, Dec 13, 2019, 2:51 PM UTC

akvadrako wrote: post #80

Scarblac wrote: post #69

Earlier quoted context omitted.

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.

It’s easy to also get the versions of all sub dependencies and put them in requirements.txt

But then you're suddenly responsible for keeping track of your subdependencies and updating the versions of each that you want. That should be up to the dependencies.

Also if you manage to drop a dependency, you don't have an easy way to remove the things from requirements.txt that are only there because they're a subdependency.

Putting it all in one requirements.txt is just too simplistic.

Re: If this project is dead, just tell us

#113

Post by Scarblac » Fri, Dec 13, 2019, 2:53 PM UTC

perlgeek wrote: post #111

Scarblac wrote: post #69

Earlier quoted context omitted.

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.

You can just 'pip freeze > requirements.txt' Boom, all recursive dependencies frozen to their current state.

But you don't want to necessarily freeze them to their current state. Yes for repeatable builds, but not in your list of dependencies. They're different concerns and Pipenv splits them.

Re: If this project is dead, just tell us

#114

Post by ryukafalz » Fri, Dec 13, 2019, 2:53 PM UTC

josteink wrote: post #43

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…

> 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. Why on earth would anyone need all this to manage packages for their projects? Are there any other programming languages whose package-management comes close to this level of intricacy and complexity? “This project needs…

>“This project needs package X”

>I mean how hard can that be to get right in a self-contained environment?

Okay, I’ll bite.

What version of package X does it need?

Is there a specific version that’s been tested with this project and is known working?

Are there specific versions of its dependencies that have been tested and are known working?

Is it needed at runtime or only at build-time?

What repository can it be found in? PyPI is not the only Python repository; private repos are common.

And as a bonus cherry on top: how easy is it to make sure you have all the project’s dependencies installed in the venv for that project, and that you don’t have packages you’re not keeping track of? This is a UX thing, but developers are human and it matters.

Re: If this project is dead, just tell us

#115

Post by guggle » Fri, Dec 13, 2019, 2:54 PM UTC

Scarblac wrote: post #69

guggle wrote: 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.

Thanks for the link, interesting read.

I still think this is all too convoluted though. I hope an accepted de facto standard for this will emerge at some point.

Re: If this project is dead, just tell us

#116

Post by vageli » Fri, Dec 13, 2019, 2:54 PM UTC

josteink wrote: post #43

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…

> 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. Why on earth would anyone need all this to manage packages for their projects? Are there any other programming languages whose package-management comes close to this level of intricacy and complexity? “This project needs…

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

> Why on earth would anyone need all this to manage packages for their projects?

> Are there any other programming languages whose package-management comes close to this level of intricacy and complexity?

> “This project needs package X”

> I mean how hard can that be to get right in a self-contained environment?

Packages often have subdependencies and their requirements at times may conflict. If you are very specific in the versions you want, it is more likely to cause issues in dependency resolution.

I would hardly call a dev's machine a "self-contained environment". Most developers I know work in a number of repos with varying requirements, and polluting their system libraries and packages with each project's requirements quickly pollutes the system and can lead to issues.

Re: If this project is dead, just tell us

#117

Post by tiborsaas » Fri, Dec 13, 2019, 2:54 PM UTC

mikkelam wrote: post #8

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

Do you think Poetry solves this package management mess?

Re: If this project is dead, just tell us

#118

Post by Finnucane » Fri, Dec 13, 2019, 2:54 PM UTC

Noe2097 wrote: post #72

ScoutOrgo wrote: post #38

Serious question, what does pipenv (and poetry) have over conda?

Conda works with a different, parallel ecosystem, whose main source of packages is managed by a single company (Anaconda Inc). That company validates, rebuilds, and possibly silently patches code, to provide their own packages. pipenv brings simpler workflow to pip. pip leverages packages which are published by their authors onto pypi, which is managed by the Python Foundation.

My limited experience is that Conda is great if you are all-in on the parallel ecosystem, but it doesn't play well with others. Or at least, it didn't for me.

Re: If this project is dead, just tell us

#119

Post by ajanuary » Fri, Dec 13, 2019, 2:55 PM UTC

akvadrako wrote: post #80

Scarblac wrote: post #69

Earlier quoted context omitted.

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.

It’s easy to also get the versions of all sub dependencies and put them in requirements.txt

That makes updating your direct dependencies harder. If you upgrade to using newer version of something, and that things dependencies have changed, you have to manually figure out which dependencies in requirements.txt were for it, and update or remove those etc.

Re: If this project is dead, just tell us

#120

Post by vageli » Fri, Dec 13, 2019, 2:58 PM UTC

akvadrako wrote: post #80

Scarblac wrote: post #69

Earlier quoted context omitted.

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.

It’s easy to also get the versions of all sub dependencies and put them in requirements.txt

> It’s easy to also get the versions of all sub dependencies and put them in requirements.txt

Is it easy to automatically do this when you want a new package version, without having to remember to do it? Is it easier to put together this process and train other developers in it and be diligent in its use? Is all of that easier than installing an application that has a similar interface to other tools, that does all that for you, and has a community of people to help with issues?