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

191–200 of 325 posts

Re: If this project is dead, just tell us

#191

Post by icebraining »

ausjke wrote: post #139

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 deactivate

In a previous job, I didn't even use venv, just "pip install -t whatever" then "PYTHONPATH= python ".

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

Re: If this project is dead, just tell us

#193

Post by shdh »

icebraining wrote: post #189
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.

requirements-test.txt

requirements-dev.txt

pip install -r dev.txt

Re: If this project is dead, just tell us

#194

Post by cassianoleal »

josteink wrote: post #24
mikkelam wrote: post #8

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

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

Golang is probably the worst. Python a close second.

Re: If this project is dead, just tell us

#195

Post by sequoia »

bluGill wrote: post #186
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 arbitr…

I haven't thought about it much and I'm not a project maintainer. As for your bus factor of 1: a) it only matters when there's actually a large group relying on your project and b) the answer is "have multiple maintainers with commit bits."

To take a shot at something "more concrete":

    * New releases will be cut at least on a quarterly schedule
    * When the number of open issues passes 25, a new maintainer shall be added (if not sooner)
    * Maintainers may leave a project at any time and are encouraged to do so if they need to move on to other things
    * Maintainers may return when they have time
    * Once per year, maintainers shall either reaffirm their desire to continue maintaining the project or step back from maintaining
    * After 2 merged PRs, a contributor is promoted to a maintainer
The main functions here are 1) add clarity to whether anyone is actually maintaining the project & who 2) Clarify that maintaining the project is an ongoing commitment & it's perfectly fine to step back from that 3) Create a mechanism to add maintainers & to signal when new maintainers are needed and 4) Create some general guidelines around releases, so people know what to expect (and know when things are no longer happening).

This is certainly not a good governance plan for everyone, some may find it too prescriptive, but it seems like it could be a good start for projects like axios & pipenv. The idea is to prevent "is this project dead" type issues before they arise. When a project is losing maintainers & no one wants to step, it's clear that the project is waning.

Of course it's also perfectly reasonable to say "that's too much work" or "f*ck off, it's my project." This convention would help people make more informed decisions when adopting a project for use. Some will be fine with "whatever", some will want a clearer plan, both are OK.

Re: If this project is dead, just tell us

#196

Post by dwaltrip »

yingw787 wrote: post #16

I’ve heard good things about pip-tools: https://github.com/jazzband/pip-tools

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.

Re: If this project is dead, just tell us

#197

Post by [deleted] »

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…

[deleted]

Re: If this project is dead, just tell us

#198

Post by yjftsjthsd-h »

gwd wrote: post #57
rthomas6 wrote: post #31

Earlier quoted context omitted.

C/C++.

C/C++'s package management story is "defer it to distributions". Personally I much prefer `apt-get install libfoo-dev` to 1) each language inventing its own incompatible system, and 2) each developer self-publishing, so there's little to no safety or accountability when adding a new dependency.

So, to be clear, I also tend to prefer distro-supported packaging. However. Forcing everything to go through the distro means that you massively limit what's available by raising the barriers to entry, you slow pushing new versions (ranging from Arch's "as soon as a packager gets to it" to CentOS's "new major version will be available in 5 years"), and you lock yourself into each distro's packages and make portability a pain (Ubuntu ships libfoo-dev 1.2, Arch ships libfoo-dev 1.3, CentOS has libfoo-devel 0.6, and Debian doesn't package it at all). When distro packages work, they're great, but they do have shortcomings.

Re: If this project is dead, just tell us

#199

Post by yjftsjthsd-h »

giancarlostoro wrote: post #124
scrollaway wrote: post #85

Earlier quoted context omitted.

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.

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

Most of those people aren't maintaining forks in any meaningful sense.

Re: If this project is dead, just tell us

#200

Post by dessant »

foob wrote: post #146
mcv wrote: post #141

Earlier quoted context omitted.

That's the real issue here: prominent, established projects recommending other projects that are not remotely as well-established as the big projects, whereas such a recommendation may suggest that it is. Big, high exposure projects should probably wait to recommend interesting new projects for actual use until they are sure that the management of that project is in reliable hands with enough backup to continue it if…

I think that's the default for most high exposure projects. Unless, of course, both projects have the same author, and that author's primary concern is increasing their own exposure.

The cult of personality that is being nurtured around certain members of the Python community definitely harms the Python ecosystem, because solutions with glaring flaws get a pass when they are stamped with someone's name, and the mismanagement of projects is rarely addressed.

Then there's also the issue of such members of the community exploiting the human tendency to worship others.

Post reply on HN