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.
If this project is dead, just tell us
151–160 of 325 posts
Re: If this project is dead, just tell us
#152Unrelated: 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?
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.
Re: If this project is dead, just tell us
#153Why 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
The Python Packaging Authority declared it the future of dependency management once upon a time and it nominally checked some important boxes such as managing a lockfile.
Re: If this project is dead, just tell us
#154I 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…
> 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...
Re: If this project is dead, just tell us
#155I 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…
> the maintainer's having written another popular project.
Potentially relevant: https://vorpus.org/blog/why-im-not-collaborating-with-kennet...
Re: If this project is dead, just tell us
#156Earlier 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…
All of those apply to Python as well except the multiple packages concern has nothing to do with a browser and everything to do with the fact that a given Python process can only load one version of a library at a time (and probably for good reason).
Re: If this project is dead, just tell us
#157Earlier quoted context omitted.
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 chang…
> Maybe they could send a heartbeat to the maintainer and simply show the project as dead as soon as there is no response? If I could not automate response to that, I'd ignore it. My employer gets to make bullshit intrusions on my time like that, no way will I waste my life on make-work from Github.
> My employer gets to make bullshit intrusions on my time like that, no way will I waste my life on make-work from Github.
You are not willing to give Github the information, if a project ,which you uploaded, is still active? But, will you give that information to users asking for details? Which way is more annoying to you and the users?
What I want to say is, that Github will turn into a huge graveyard in the years to come, with projects long forgotten still having a landing page like it's the best thing ever. Do you want every visitor to first contact the maintainer if the thing is still alive? Isn't that a huge waste of time?
In my opinion, Github will have to clean up the mess left behind by unmaintained projects at some point. The sooner they start, the easier it will be.
Re: If this project is dead, just tell us
#158669 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.
Take SpeedCrunch for example: the current release (0.12) dates from 2015 AFAICS, and works very well for the most part.
There's a bug in that release though: it thinks 0^1 is NaN. That bug was fixed in or before 2018 (https://bitbucket.org/heldercorreia/speedcrunch/issues/836/0...), but there has not been a release since. There have been a number of commits this year, but not a lot.
Is the project dead or not? I honestly couldn't tell.
Re: If this project is dead, just tell us
#159Earlier 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…
Maven basically solved Java's dependency problems back in 2005.
Re: If this project is dead, just tell us
#160I 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…
> 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 Python core team. PyPA (Python Packaging Authority) is a separate organization — they are responsible for the packaging parts (including pypi.org, setuptools, pip, wheel, virtualenv, etc.) of Python