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

Re: If this project is dead, just tell us

#181

Post by crucialfelix » Fri, Dec 13, 2019, 4:00 PM UTC

jancsika wrote: post #175

rthomas6 wrote: post #28

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

> The question is, which fork do I use? Return the forks of developers who have publicly stated they'd like to take over maintenance of this project. I'd bet that narrows it to less than ten. Now-- have a look at the blog posts where these maintainers explain their plan to sustain the project going forward and choose the most persuasive one. I'd bet it's less than one. Short circuited, problem solved. :)

PIL -> Pillow

pipenv -> pippi

They could call it pippi

Re: If this project is dead, just tell us

#182

Post by CivBase » Fri, Dec 13, 2019, 4:01 PM UTC

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.

Re: If this project is dead, just tell us

#183

Post by noname120 » Fri, Dec 13, 2019, 4:05 PM UTC

jplayer01 wrote: post #160

noname120 wrote: post #154

Earlier quoted context omitted.

> The python packaging team was officially recommending it NO! This is a common misconception[1]. Edit: Correction it's not endorsed by the core Python team but it's recommended by the Python Packaging Authority in various places. See replies below for more info. [1] https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-l...

Look, if you can’t trust the endorsement of the organization that otherwise develops and maintains all of Python’s official packaging tools, who are you supposed to trust? Guido and only Guido? > The thing that made it “official” was a short tutorial [1] on packaging.python.org, which is the PyPA’s packaging user guide. Also of note is the Python.org domain used. It makes it sound as if Pipenv was endorsed by the Pyt…

True. This same tutorial cites pip-tools, hatch, poetry. Does that mean that they “endorse” these tools as well?

Re: If this project is dead, just tell us

#184

Post by williamdclt » Fri, Dec 13, 2019, 4:07 PM UTC

scrollaway wrote: post #134

tiborsaas wrote: post #117

Earlier quoted context omitted.

Do you think Poetry solves this package management mess?

To a point. Poetry still isn't fully in board with being a project manager, it focuses too much on packaging. For example it doesn't do project scripts like nom scripts.

To be fair, NPM really doesn't do a great job at project scripts

Re: If this project is dead, just tell us

#185

Post by icebraining » Fri, Dec 13, 2019, 4:08 PM UTC

worldsayshi wrote: post #36

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.

In the past I've used a tool to aggregate those PRs: https://github.com/acsone/git-aggregator

Re: If this project is dead, just tell us

#186

Post by bluGill » Fri, Dec 13, 2019, 4:08 PM UTC

sequoia wrote: post #131

This "project dead?" question pops up on many open source projects on github. One recent one: 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…

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)

Re: If this project is dead, just tell us

#187

Post by icebraining » Fri, Dec 13, 2019, 4:10 PM UTC

xenator wrote: post #126

jtdev wrote: 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

Pipenv uses hashes to make sure the files are really the same, not just packages with the same version number.

Re: If this project is dead, just tell us

#188

Post by theamk » Fri, Dec 13, 2019, 4:10 PM UTC

mateuszf wrote: post #79

theamk wrote: post #48

Earlier quoted context omitted.

Cmake? (And especially Kitware Superbuild... try pinning packages there!)

Isn't it a build tool, not package manager?

It is used as package manager often enough -- stick "git clone", or ExternalProject into the CMakefile and you have the (bad) equivalent of "pip install" for C++.

For example, I mentioned "kitware superbuild" above. It describes itself [0] as:

> It is basically a poor man’s package manager that you make consistently work across your target build platforms

[0] https://blog.kitware.com/cmake-superbuilds-git-submodules/

Re: If this project is dead, just tell us

#189

Post by icebraining » Fri, Dec 13, 2019, 4:12 PM UTC

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

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.

Re: If this project is dead, just tell us

#190

Post by theamk » Fri, Dec 13, 2019, 4:15 PM UTC

tsukurimashou wrote: post #103

theamk wrote: post #37

Earlier quoted context omitted.

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.

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.