
If this project is dead, just tell us - omni
https://github.com/pypa/pipenv/issues/4058
======
sequoia
This "project dead?" question pops up on many open source projects on github.
One recent one:
[https://github.com/axios/axios/issues/1965](https://github.com/axios/axios/issues/1965)

The issue seems to be similar to one that we programmers regularly encounter
in our day jobs: failing to consider maintenance and/or make a plan for what
happens to a project in one, two, or three years. I don't mean to say "the
authors of this project failed to consider maintenance" I mean "we, _the whole
community_ , including maintainers _and consumers_ of the project, took
maintenance for granted or were not concerned about it." Anyone who installed
the tool without reading the project's governance model and maintenance plan
signed up for "whatever happens happens," the governance model of most small
projects. _I myself do this all the time_ , I'm not saying I'm better by any
means. To participate in the JavaScript/Python/etc. ecosystem generally
requires being OK with this.

To me this isn't a question of one project, it's a question of OSS project
governance in general. Is there a succession plan? How do you know when more
maintainers are needed? How do you promote someone from contributor to
committer to releaser?

We went around adding CoCs to everything a few years ago, perhaps a similar
effort could be made with governance plans? Like a boilerplate plan projects
could use, hopefully leading to a new community norm of "if you are using a
project with no governance plan, that's up to you, but don't say you weren't
warned!"

~~~
bluGill
Can you suggest something a little more concrete? What should I add to my
project so that if I die tomorrow the project can continue without me?

I work on a small project. I didn't add a CoC when the big push came about
because I concluded that it was if I say it is bad it is bad, otherwise it is
good - that is no CoC and so there is no point. (I did consider asking some
large project - KDE for example - to be arbitrator, but I didn't bother)

~~~
medmunds
I’m in a similar situation, maintaining a project that’s used widely enough it
should probably have a continuity plan, but not enough that it’s developed a
robust community of other contributors who could step in.

Jazzband [0] seems meant to address exactly this: “a collaborative community
to share the responsibility of maintaining Python-based projects.” And it
looked promising, but it’s not entirely clear that the Jazzband project itself
is all that active (only news status update is the launch announcement from
2015; last public Twitter activity was in 2017).

[0]: [https://jazzband.co/](https://jazzband.co/)

~~~
medmunds
Oh, just realized that pip-tools (being discussed favorably downthread as a
pipenv alternative) is a Jazzband member project:
[https://github.com/jazzband/pip-tools](https://github.com/jazzband/pip-
tools).

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

~~~
strunz
Can you link to one of these times a maintainer said something like that?

~~~
xenator
I put myself in very uncomfortable position. When I need to prove my words by
blaming someone who did very good job for the community in general. At least
have these good intentions. And the same time I don't want shame somebody in
public.

I did some research and think this link is enough
[https://github.com/pypa/pipenv/issues/1137](https://github.com/pypa/pipenv/issues/1137).

~~~
cerberusss
Wow... some users are subtly pressuring the maintainers into work here. The
maintainer simply states "works as intended".

The users in that topic then continue the discussion in all of its aspects,
expecting the maintainer to engage with them. I can imagine it feels to the
maintainers as an energy-sucking discussion.

IMHO, you're not shaming the maintainers, you're shaming the community here.

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

~~~
zubspace
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?

~~~
the_duke
You said it yourself, this is a very hard problem.

There are Java packages that haven't seen a commit in years and are still
perfect for a task. There are npm packages that are 2 months old and terribly
outdated and unmaintained.

My personal favorite metric is "time to maintainer response": how long does it
take for a maintainer to respond to issues or pull requests. Not necessarily
to resolve them, but triage issues or provide guidance on a PR.

If this happens quickly and with reasonable responses, projects are usually
solid, assuming they have existed for a while and see decent usage.

~~~
slantyyz
> There are Java packages that haven't seen a commit in years and are still
> perfect for a task.

My favorite is Scriptella
([http://scriptella.org/download.html](http://scriptella.org/download.html))
which recently just got its first update in around 7 years.

For what it does, it just worked, and for many uses cases, updates were never
an issue.

~~~
ejboy
Author of Scriptella here. Thank you for mentioning it! The product was
neglected for many years, but I never was ready to finally press the kill
switch. Hoping that one day I will have more time to work on it...

I cannot promise active feature development, but at least keep it compatible
with recent JDK versions. Let me know if you have any feature requests on
[https://groups.google.com/forum/#!forum/scriptella](https://groups.google.com/forum/#!forum/scriptella)
or [https://github.com/scriptella/scriptella-
etl](https://github.com/scriptella/scriptella-etl)

~~~
slantyyz
I think Scriptella is fantastic. It does one thing extremely well, and for me,
that's all I can ask for.

------
geekles
Meanwhile, Poetry just announced 1.0: [https://python-
poetry.org/blog/announcing-poetry-1-0-0.html](https://python-
poetry.org/blog/announcing-poetry-1-0-0.html)

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

~~~
duckerude
DepHell claims to be able to convert to and from pip, pipenv and poetry, so
perhaps that could be used for migrating?

[https://dephell.org/docs/cmd-deps-convert.html](https://dephell.org/docs/cmd-
deps-convert.html)

~~~
kstrauser
We _love_ DepHell. I migrated some work repos from Pipenv (and plain ol' pip)
to Poetry. However, we didn't want to have a flag day where we updated our
build tooling to be 100% Poetry, so I made a Makefile target that builds
requirements.txt and setup.py from pyproject.toml. Now developers can work
with pleasant tooling, but the build system can use the old stuff it already
knows.

We're close to having everything migrated to Poetry. When that day comes, we
can throw out all the compatibility stuff, update the build server, and be
happy. Until that day, DepHell gives us an easy compatibility layer so that we
don't have to do the migration all at once. It's awesome.

------
bnjmn
Speaking as a maintainer of large open-source projects, I know what it's like
to get stuck working on a release branch (which is sometimes just the `master`
branch) that takes forever to become an official release. I'm not sure if
that's the story here, but there have been a lot of commits since the last
release, so maybe?

In any case, I strongly recommend publishing alpha/beta releases along the
way, without the ceremony of an official release, so that folks can give
feedback during the long months that fly by when you don't have nearly enough
time to spend on the project.

Respect the needs of your conservative users by not publishing official
releases until they're really ready, but trust your more engaged users to use
whatever you have right now, and let you know what's working/broken, without
judgment.

------
staticassertion
Not dead.
[https://github.com/pypa/pipenv/issues/4058#issuecomment-5655...](https://github.com/pypa/pipenv/issues/4058#issuecomment-565550646)

~~~
jlv2
Not dead _yet_.

~~~
rolandog
Technically, that applies to everyone of us, and every product---or service---
we use...

~~~
ben509
Technically, there is an infintesimal chance that entropy spontaneously
reverses permanently and that nothing ever dies.

------
mikkelam
Pipenv has spawned so much controvery.. One big shitfest.

Python packaging in general is such a messy ecosystem

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

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

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

~~~
egeozcan
NPM itself was also not great, but did become great in the last majors. The
weakness of the stdlib is still a problem but very, very slowly getting better
with the new Ecmascript and node.js versions.

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

~~~
alecbenzer
> the maintainer's having written another popular project.

Potentially relevant: [https://vorpus.org/blog/why-im-not-collaborating-with-
kennet...](https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-
reitz/)

~~~
jlengrand
Holy crap. I had never heard of anything like that regarding him

------
css
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](https://docs.python.org/3/library/venv.html)

~~~
sidmitra
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 for their config, or have PRs
pending.

~~~
YPCrumble
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?

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

------
yingw787
I’ve heard good things about pip-tools: [https://github.com/jazzband/pip-
tools](https://github.com/jazzband/pip-tools)

~~~
dwaltrip
We also recently switched from Pipenv to pip-tools and so far it has been very
pleasant.

Our workflow:

\- Use pyenv to manage python versions (mostly works pretty well)

\- In the beginning, use builtin python 3 tooling to create virtual env for
the project: "python3 -m venv venv"

\- Whenever needed, add new libs to "requirements.in"

\- Run the "pip-compile" command to generate a new "requirements.txt" with the
dependency and its sub-dependencies pinned by default to the exact version

\- Run "pip install -r requirements.txt" to install the new package and its
sub dependencies

\- Check both requirements.in and requirements.txt into version control

The big advantage is that requirements.in specifies just the packages you care
about, while requirements.txt has your packages and all of the sub
dependencies pinned to the exact version.

~~~
acemarke
The `pip-tools` portion of that is basically what I came up with myself and
described in another thread at
[https://news.ycombinator.com/item?id=21779929](https://news.ycombinator.com/item?id=21779929)
, except that I'm trying to use `pythonloc` to install things in a local
`__pypackages__` folder per PEP-582 instead of using venvs.

------
infecto
I was pretty badly turned off by Kenneth Reitz and the way he handled conflict
with Pipenv. I disliked how instead of listening to feed back or being
constructive he just gave off a kind of fuck you attitude. There were real and
critical issues with pipenv that he would not budge on and it truly felt like
he was in the minority. I know, its his project he can do what he wants but in
the context it did not make sense. I especially disliked it due to how he sold
Pipenv as being officially endorsed by Python (which its not and has never
been) but it did trick me for a short time. Finding out it was never official
endorsed is what made me never want to support any of his projects again.

Posting this here again in case anyone missed it.
[https://vorpus.org/blog/why-im-not-collaborating-with-
kennet...](https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-
reitz/)

~~~
shakna
> Use Pipenv to manage library dependencies when developing Python
> applications. See Managing Application Dependencies for more details on
> using pipenv.

> Consider other tools such as pip when pipenv does not meet your use case.

Is this [0] not an official endorsement? It certainly seems as much.

[0] [https://packaging.python.org/guides/tool-
recommendations/](https://packaging.python.org/guides/tool-recommendations/)

~~~
jzl
Those pages are managed by the "PyPA" group, not technically python.org
itself, although they were given a subdomain there. Start here and follow the
links for more info: [https://hynek.me/articles/python-app-
deps-2018/](https://hynek.me/articles/python-app-deps-2018/)

~~~
shakna
I'm aware that the Python Packaging Authority is not the Python Software
Foundation. But they are also the Packaging Authority.

The PSF may not have officially granted them some sort of status, but as PyPA
maintain pip, setuptools and warehouse, they are in fact the authority when it
comes to packaging, unless the PSF comes out with a statement saying they
aren't.

------
valdiorn
This 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?

~~~
rthomas6
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 and do
maintenance on the project, that IS a problem, since they're supposed to be
the official version right now.

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

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

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

~~~
yjftsjthsd-h
_Most_ of those people aren't _maintaining_ forks in any meaningful sense.

------
have_faith
> I don't think you're bad people, but the least y'all can do is be honest

I don't like this framing (sort of implies they aren't be honest) but
regardless just switch if you're not happy with the release frequency and you
have viable alternatives.

~~~
giancarlostoro
Especially if they haven't even said anything yet. A better suggestion would
be "It's okay if you're not working on this, but let the community know." I
have a feeling some use this for production grade work.

------
at_a_remove
I am one of those grubby little "dark matter" developers. I fled Perl for
Python over a decade ago. While I do love Python, one of the impediments (not
the only, and perhaps not the largest) to my progress are the endless
packaging issues. Among the larger attractions to Python is that there is
supposedly one obvious way to do things and here there is not. Instead, I must
make my selection largely based on opinions that have the same foreboding
stink of those I associate with arguments over Linux distros: dashed-off
dismissals starting with "just" and drive-by engagements with the topic.

As a result, I end up rarely going outside of the standard library. In a
perverse way, being locked on an un-upgradable (due to Reasons) version of
Python 2.7.5 for the foreseeable future has helped put that temptation a bit
further away.

Yes, Packaging Is Hard. It is certainly beyond me. I will probably never need
to package anything I wrote, much less distribute it, so many of my concerns
are purely academic.

Rather than fussing over things like the walrus operator (really, c'mon), I
would love to see those who steer Python buckle down on issues like this,
solve them, and then relentlessly backport the solution further back than
everyone _thinks_ is reasonable.

------
fulldecent2
Here's how you solve this problem. I do this on my own projects and with
Chart.js which we resurrected from the brink of a "2.0 is coming... please
wait" cliff.

1\. Add a project scope to the README -- this gives you and volunteers grounds
to close issues that are not relevant. 2\. Send a personal email to your 3 top
contributors -- ask if you can give them push access (even if they aren't
recent contributors) at a minimum as an insurance policy. 3\. Automate or at
least specify your release process. You should be able to do this reliably,
while drunk and high, and when you have 17 other projects needing your
attention. Example:
[https://github.com/fulldecent/FDWaveformView/blob/master/CON...](https://github.com/fulldecent/FDWaveformView/blob/master/CONTRIBUTING.md#release-
process)

I have been involved in a few "takeovers" to implement the above and keep
great projects running. A little structure and human goes a long way. You
don't need to fork and be the new dictator to keep something great moving.

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

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

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

~~~
kwooding
This may have been true at the beginning, but nowadays I use “pip install”
extensively in conda-created environments. Are there particular packages that
you have trouble with?

~~~
cjbillington
The problem with this is that pip will install dependencies of the package
you're installing, not knowing (or caring) that those dependencies are already
available in the conda repositories.

Later, conda may install a different version of the same dependency as a
dependency of something else. Depending on how exactly they are installed
(egg, zipped egg, whether the folder has the version number in it), you either
get two versions of the same package installed, with which one gets imported
being arbitrary, or you get two sets of metadata, with one of them not
matching what is actually installed, such that pip may think version
requirements are satisfied when they are not. It's messy as anything, and the
breakage can be subtle. I distribute packages to users who use conda, and my
packages have dependencies that are available in conda, so this has been
messing with a lot of my users' installs. I'm now just making conda packages
for these projects to solve the issue.

I made this package [1] to try and automate the process of making conda
packages out of my existing setuptools packages, I'm quite happy with it but
since it is designed to serve the needs of my projects, I can't guarantee it
will suit everybody's needs.

[1]
[https://github.com/chrisjbillington/setuptools_conda](https://github.com/chrisjbillington/setuptools_conda)

------
shkkmo
Some other related HN threads for those that, like me, might be missing some
of the context here:

[https://news.ycombinator.com/item?id=18612590](https://news.ycombinator.com/item?id=18612590)

[https://news.ycombinator.com/item?id=19826680](https://news.ycombinator.com/item?id=19826680)

------
kresten
It does seem dead.

The dead don’t speak.

And no one is replying to this question.

~~~
shkkmo
There was a pull request merged a month ago. Looking at the commit history it
doesn't seem dead to me. It might be more accurate to call it "poorly managed"
or "uncommunicative".

------
CivBase
I finally tried out pipenv a few months ago but I ran into a huge showstopper:
pipenv does not allow you to target multiple versions of Python. I've seen
sever pull requests requesting this feature but the author has officially
stated that he does not plan to support it.

My company still primarily uses Python 2, but I've been trying to push them
towards 3. I need to support both in the mean time and that simply isn't an
option with pipenv. If pipenv truly does die out and something else takes the
spotlight, I really hope they include the feature.

~~~
kwooding
This is the main reason I use conda to manage python virtual envs. It easily
supports multiple python versions.

------
jlg23
An issue that was opened 16h ago, now on HN? If I was in the maintainer's
position I'd not respond now just so I don't create a precedent. This _looks_
like bullying.

~~~
jzl
This has been a many-years long simmering issue.

------
manx
I think for each project on Github it would make sense that the community can
vote to have their own "official" community fork. PRs are then accepted by
community approvals.

Changes can be merged back to the original repo. The maintainer could also
declare the community fork to become the official project (and get its name).

This avoids lots of hassles with blaming the maintainer or organizing the
community who want to help.

------
specialist
Roles in a project should auto expire. Just like DHCP leases, or certificates,
or elected offices, or...

Alternately, wire up an instance of The Button for each project. If a
project's instance ever hits zero, someone else can adopt the project.

[https://en.wikipedia.org/wiki/The_Button_(Reddit)](https://en.wikipedia.org/wiki/The_Button_\(Reddit\))

------
worldsayshi
For situations like this it would be very useful if there was a way to easily
share or make use of PR:s and issues of forked repos. I mean it sounds quite
unnecessarily labor intensive to just create a fork and start merging those
PR:s?

That way the barrier for moving to a diffident fork would be lowered.

~~~
icebraining
In the past I've used a tool to aggregate those PRs:
[https://github.com/acsone/git-aggregator](https://github.com/acsone/git-
aggregator)

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

~~~
jawilson2
We have a lot of python code, along with C++ and Java, and it is an absolute
nightmare dealing with python. If we include conda-forge as a channel,
dependency resolves can take hours with the right/wrong combination of
packages. We can't easily replicate environment across machines, and build
times for our conda packages can take tens of minutes, just to copy a few py
files around. We hate it, but our ecosystem is built on it (data
science/ML/etc), so it is what we have to deal with. I always look at these
threads with hope, but then envision the nightmare that would be involved in
moving to poetry or some other system.

------
darepublic
Python ecosystem is weird tried many different so called solutions ie
anaconda, pip and the like. Admittedly I am a python beginner so may be very
wrong in this? But this kinda confirms to me that there is no one good
solution yet.

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

~~~
kawsper
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](https://github.com/beanstalkd/beanstalkd/issues/399)

------
ausjke
used to mainly/solely use pipenv, since it is in stale for quite a while now,
I switched to the default venv, good enough for my use cases, and probably for
90% of other's user cases as well, I no longer feel pipenv is that important
at all, get over with it, and move on.

    
    
        python3 -m venv myvenv
        source myvenv/bin/activate
        pip install -U pip
        pip install whatever
        <do whatever>
        deactivate

~~~
icebraining
In a previous job, I didn't even use venv, just "pip install -t <dir>
whatever" then "PYTHONPATH=<dir> python <args>".

And of course, you could just wget the packages from PyPI and run setup.py...

------
jimws
What are the advantages of pipenv compared to plain pip and python3 -m
venv/virtualenv?

The latter works fine for me. What are good reasons to switch to pipenv?

~~~
kstrauser
The problem is that plain pip does not resolve incompatible dependencies.
Pipenv (and better: Poetry) do. Here's an example:

You project depends on packages Spam and Eggs. Both of them depend on another
package, Foo. The problem is, maybe that don't depend on the _same_ version:

Spam 1 depends on Foo 2 or newer. Spam 2 depends on Foo major version 2, but
it's known to be broken with Foo 3.

Eggs 1 depends on Foo 2 or newer. Eggs 2 requires some of the new features in
Foo3.

If you run "pip install spam eggs", it will do something like this:

\- Spam version 2 is the newest, so I'll install that.

\- Spam 2 depends on Foo 2, so I'll also install Foo 2.

\- Eggs 2 is the newest, so grab it!

\- Oh no! Eggs 2 depends on Foo 3, but we've already installed Foo 2, so I'll
warn you that I couldn't install Foo 3 and then keep on going.

Now you're in a state where "import eggs" will fail because its dependency on
Foo 3 wasn't satisfied.

Suppose you use Pipenv (or better: Poetry) instead. It will do something like
this:

\- What's the newest version of Foo that can satisfy requirements for both
Spam and Eggs?

\- What's the newest version of Spam and Eggs that can use the version of Foo
we identified in the previous step?

\- Install Foo 2, Spam 2, and Eggs 1.

Now you have Eggs 1 instead of Eggs 2, but all the versions play nicely
together. And if you say "but I really want Eggs 2!", it would give you an
error message like "well, that requires Foo 3, but that means you'll have to
roll back to Spam 1. Are you OK with that?" The point is that it figures all
this stuff out for you and gives you the information to make smart decisions.

This is "dependency resolution". Poetry is great at it. Pipenv is decent at
it. Pip doesn't do it at all. That's the real reason these tools are becoming
popular.

------
tus88
Grumpy old virtualenv user trying not to be smug.

------
darepublic
If we aren't going to make the delivery deadline, just tell us.

------
Akababa
I wonder if some automatic governance model could be put into place to ensure
a project never dies. Of course anything I can think of has the potential for
abuse so maybe forking is the best solution after all.

------
The_rationalist
The same thing could be said of the X server.

------
peterwwillis
the definition of passive aggressive issues

------
ossworkerrights
Here is a radical approach to software development. Paying for it's
development and maintenance. How does that sound as a disruptor? Pay for
pipenv's continued development, and for other software you use and depend on.

------
jtdev
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?

~~~
icebraining
How do I declare packages needed for development/testing but not production?

Yes, pipenv is mostly just a frontend to pip+venv, but that doesn't mean it
isn't useful.

~~~
shdh
requirements-test.txt

requirements-dev.txt

pip install -r dev.txt

~~~
icebraining
But then you can't "pip freeze" to get specific versions for production
deployment.

------
qatanah
I think it applies to all open source projects.

~~~
mfcl
What applies to all open source projects?

~~~
sgt
That if you don't regularly commit or if there's no PipenvCon in Las Vegas,
it's considered dead.

~~~
icebraining
But there are regular commits. Just no releases.

------
Abishek_Muthian
Unrelated: Is there anyone here who has substantially large project, which
they would like to open-source but have refrained from it in the fear of
getting dissed by the community because it wasn't written up-to standards or
you know you'll not be able to maintain it?

~~~
aequitas
Not big projects but this was my fear when I started open sourcing my hobby
projects. At one point you will learn how to stop worrying and love the open
source.

There will be all kinds of responses. Indeed, people complaining about the
quality, but also poeple how help you get up to standards (also remember,
there is not one standard). People who find a spelling error in your README.md
and make their first open source contribution to help you fix it. From hostile
complainers to humble user. You can get the entire spectrum.

Find your own level of engagement and don't try to get stressed out by feeling
guilty. But whatever you do, imho, always communicate something. Just putting
a text at the top of your project's readme that you have taken a break and
don't know when you return is always better then leaving people guessing.

As for the Pipenv project. I think people kept it at the highest standard
because it was actively endorsed to be the one true new way of package
managing, but anded up not trying to solve everyones problem. It's ok if you
don't want to solve everyones problem, but make that clear in how you promote
your project, not through shutting down issues and PR on the backside.

------
wrongsystem
PACKAGE SIGNING IS MORE IMPORTANT!

Absurd discussions about micro features in packaging tools while ignoring that
huge security elephant - disgusting.

Yo brotha, go on pip loading my exploits from your amateurish distribution
infra! RIDICULOUS!

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

~~~
theamk
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?

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

~~~
theamk
Do you think that a trivial, 4-line commit to README saying "this project is
no longer maintained, look elsewhere" is too much to ask?

I agree that you cannot force people to give their time away, and anyone can,
and should be able to, stop maintaining any project they have.

But putting "I am done" notice will likely take under 30 minutes, and will
help a lot of people. It's a good idea to do it just out of respect to all
those people who spent their time crafting those 669 commits which will never
get to release now.

~~~
tsukurimashou
project maintainers are not your bitch, a lot of things can happen that could
make them not add that line

