19 ms·

If this project is dead, just tell us

• kresten 7y ago
  It does seem dead. The dead don’t speak. And no one is replying to this question.
  • fullstop 7y ago
    > And no one is replying to this question. I'm a ghoOoOoOst!
    • skavi 7y ago
      The fading from the downvotes actually makes this comment amusing now. More so than before at least.
      • deleted 7y ago
        [deleted]
  • shkkmo 7y ago
    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".
  • fwip 7y ago
    The issue was posted 13 hours before your comment. I think it's reasonable to wait at least a day for somebody to respond before pronouncing them dead.
• css 7y ago
  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
  • nurettin 7y ago
    pipenv install --dev is one reason I guess and pipenv uninstall x gets rid of all the dependencies, that's nice to have
  • sidmitra 7y ago
    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.
    • josteink 7y ago
      > 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? This whole story is just madness coupled deep denial and Stockholm-syndrome.
      • ryukafalz 7y ago
        >“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.
• have_faith 7y ago
  > 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 7y ago
    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.
  • dedsm 7y ago
    there are a couple of issues with "moving on", since the project is owned by pypa, it feels it should be the default for python projects, pipenv has a good idea, but in my opinion, a flawed implementation, and maybe all my issues are already resolved in those 600+ commits without release. About the framing of the question, I think it's because of all the flame wars in the past when people criticized pipenv and maintainers took it a bit personal.
  • gonational 7y ago
    For me, and perhaps others, there is a desire to see this project explicitly move aside (vs slowly die), so that poetry and other projects can take the reins. A lot of people say “just fork it” or “choose something else”, but the problem is that python is a finite community with a finite amount of energy, and a lot of this energy has been absorbed by the star power Kenneth acquired from his prior successes (namely, requests... which btw now has an even better replacement called httpx). It’s almost like Kent needs to come out and say “I’m sorry I screwed up, here’s my towel; good night.”, so that people can move on.
• mikkelam 7y ago
  Pipenv has spawned so much controvery.. One big shitfest. Python packaging in general is such a messy ecosystem
  • briandilley 7y ago
    Biome. We no longer say ecosystem, we say "Biome".
    • emddudley 7y ago
      OK so we're sidetracking here, but I have never seen anyone use "biome". Why change from "ecosystem"?
      • MS90 7y ago
        Curious as well. The thesaurus lists them as synonyms, though it appears there are some minor differences in meaning when used as scientific terms.
  • josteink 7y ago
    > 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.
    • deleted 7y ago
      [deleted]
    • rthomas6 7y ago
      C/C++.
      • gwd 7y ago
        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.
• valdiorn 7y ago
  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?
  • dagurp 7y ago
    There's 1400 forks. I'm sure that people will move to one of them if the original is pronounced dead.
    • goerz 7y ago
      The question is who will have access to make new releases on the Python Package Index. Otherwise, they'd have to find a new name for their fork.
    • justincormack 7y ago
      That normally means there have been 1.4k pull requests not 1.4k people actively maintaining forks.
  • theamk 7y ago
    The problem is the name, not the content. There are lots of guides, blogposts, etc which say “use pipenv, is awesome”. However, if one actually tries to do this, as the bug says, one gets a very old release with seemingly no chances for bugfixes, etc.. This means a bad experience for people who try to use it, and makes whole Python ecosystem feel a tiny bit worse too. Imagine a frustration of someone reading the blog post , spending all the time learning about system, using it, and then discovering bugs won’t ever get fixed! It is very easy to fix by an author: just a small, 4 line commit to readme and website saying “the project is dead , go elsewhere”. This will allow people to move on - maybe to a fork, or to some other project which does similar thing.
  • rthomas6 7y ago
    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.
• qatanah 7y ago
  I think it applies to all open source projects.
  • mfcl 7y ago
    What applies to all open source projects?
    • sgt 7y ago
      That if you don't regularly commit or if there's no PipenvCon in Las Vegas, it's considered dead.
      • icebraining 7y ago
        But there are regular commits. Just no releases.
    • chapium 7y ago
      A final "please fork me" commit
• peterwwillis 7y ago
  the definition of passive aggressive issues
• yingw787 7y ago
  I’ve heard good things about pip-tools: https://github.com/jazzband/pip-tools https://github.com/jazzband/pip-tools
  • aequitas 7y ago
    I recently switched from Poetry (to which I switched after pipenv) to pip-tools for some projects, because Poetry was not able to work properly with some dependencies. Pip-tools has been a dream. It is just a thin layer of tools on top of Pip that separates your 'abstract' requirements (eg: django<3) from your 'release' requirements (eg: django==2.2.5) and managing running pip to have your virtualenv reflect your exact requirements. No new standard like pyproject that is partially supported (by 3rd party that is), no intention to (but failing at) being the all dominating way to do python packaging. Just a tool that is there to help you. edit: it also automates updating the release requirements file (within the constraints of the abstract requirements).
    • yingw787 7y ago
      I’ve heard good things wrt determinism and packaging for different environments (dev/test/prod) on top of the simplicity!
      • aequitas 7y ago
        Have a look at https://github.com/jazzband/pip-tools#workflow-for-layered-requirements https://github.com/jazzband/pip-tools#workflow-for-layered-r... Both the 'input' and 'output' requirements are pip compatible files (just with different extensions). It uses pip features like '-c' to include other contraints in your requirements. For me, if they would merge Pip-tools into Pip and call it a day, my package management issues for Python are solved.
    • cik 7y ago
      Thanks for this. I've been a poetry fan since... the first release and pipenv really just fails for me. I'm going to check out pip-tools today.
• casion 7y ago
  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.
  • petters 7y ago
    It may be abandoned by everyone with release permissions.
    • shakna 7y ago
      Most of the 2018 release were by techalchemy, who made commits in July. Right now, it seems like the issues raised in [0] are still a problem. The release pipeline has problems, and dragging through that isn't a priority. [0] https://github.com/pypa/pipenv/issues/3742 https://github.com/pypa/pipenv/issues/3742
  • guardian5x 7y ago
    He talks about maintenance and making releases. Otherwise people will still deal with bugs in the "current" release that have been fixed in the master branch for a long time.
    • casion 7y ago
      That would be mismanagement (and annoying of course), not "dead" I would think?
      • nwsm 7y ago
        There is no difference for the average user. I'm not going to use the code in master, I will use a package from pip, pipenv or otherwise.
        • setr 7y ago
          And even if you did, there's no guarantee that the work in master is actually in a sane state. Some try to follow models like master is always runnable, or tested/built by ci/cd, but it's often simply not the case. I've worked on atleast a few open source projects where I'd pull and build master, trying to obtain a particular bugfix, and it would fail, and I'd have to randomly rollback commits until I found a working build. In one case the project had a seperate repo for a library that wasn't kept entirely in sync with the parent project.. had to randomly move back both repos until I found a matching pair that built and ran successfully, but after the bugfix was implemented. Releases are important for anyone who isn't working on the repository directly -- they gaurantee the project is in a sane state.
• fiatjaf 7y ago
  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.
  • AnIdiotOnTheNet 7y ago
    Because resumes aren't made by maintaining existing well-working software.
  • theamk 7y ago
    You look at the issues list to see if this is the case. This project has 313 open issues. No, everything’s does not already work.
  • xboxnolifes 7y ago
    But there are commits.
  • rthomas6 7y ago
    This is a good question. I have wondered the same thing about software in general. In this specific case, though, there are 313 open issues and 33 pull requests. So people are finding bugs in the current version (and fixing them).
  • jedieaston 7y ago
    Pipenv isn't stable and reliable yet though, at least compared to pip+venv. The tooling is really handy and it makes it in theory easier to write Python code, but in practice there is still work to be done.
  • kawsper 7y ago
    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
• tsukurimashou 7y ago
  > 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 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
          project maintainers are not your bitch, a lot of things can happen that could make them not add that line
• geekles 7y ago
  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 7y ago
    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.
    • deleted 7y ago
      [deleted]
    • rbongers 7y ago
      There is also a bug that is keeping me from switching, and also the handling of that bug has not been great, otherwise I would do so in a heartbeat.
      • deleted 7y ago
        [deleted]
    • duckerude 7y ago
      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 7y ago
        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.
• worldsayshi 7y ago
  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 7y ago
    In the past I've used a tool to aggregate those PRs: https://github.com/acsone/git-aggregator https://github.com/acsone/git-aggregator
• ScoutOrgo 7y ago
  Serious question, what does pipenv (and poetry) have over conda?
  • Noe2097 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
          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
• bnjmn 7y ago
  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.
• shkkmo 7y ago
  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
• jtdev 7y ago
  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?
  • snypox 7y ago
    Everything you just wrote basically.
  • xenator 7y ago
    Also: pip freeze > prod.txt And then on production environment: pip install -r prod.txt
    • icebraining 7y ago
      Pipenv uses hashes to make sure the files are really the same, not just packages with the same version number.
      • xenator 7y ago
        I agree that mostly hashes do their job. The same time I think there is some corner cases. As nature of the python packages can be a bit different comparing to the other packaging systems. File setup.py actually is python file and it is executed when processes. So, it possible that depending on existence of some libraries on your system you will get very different results. For example packages can require very different dependency if you build on Windows or Linux. This case hashes can't do much to guaranty consistency.
  • icebraining 7y ago
    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 7y ago
      requirements-test.txt requirements-dev.txt pip install -r dev.txt
• Abishek_Muthian 7y ago
  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 7y ago
    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.
• jimws 7y ago
  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 7y ago
    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.
• xenator 7y ago
  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 7y ago
    Can you link to one of these times a maintainer said something like that?
    • xenator 7y ago
      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 7y ago
        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.
    • 7y ago
• reledi 7y ago
  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 7y ago
    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.
• coleifer 7y ago
  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.
  • mcv 7y ago
    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 the original creator vanishes.
    • foob 7y ago
      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.
      • dessant 7y ago
        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.
        • lainga 7y ago
          Do you think this is unique to the Python community? Any thoughts as to why it might be so?
• The_rationalist 7y ago
  The same thing could be said of the X server.
• sequoia 7y ago
  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!"
  • JulianMorrison 7y ago
    Broadly, "a project is being actively developed and makes releases reliably often" is a fairly tolerable maintenance plan. It's only when that implicit contract breaks down that you get "is X dead?"
  • bluGill 7y ago
    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)
    • 7y ago
• ausjke 7y ago
  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 7y ago
    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...
• at_a_remove 7y ago
  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.
  • deleted 7y ago
    [deleted]
• Akababa 7y ago
  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.
• wrongsystem 7y ago
  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!
  • deleted 7y ago
    [deleted]
• CivBase 7y ago
  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 7y ago
    This is the main reason I use conda to manage python virtual envs. It easily supports multiple python versions.
  • mixmastamyk 7y ago
    It does support pyenv, does that not work for you?
• infecto 7y ago
  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-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet...
  • shakna 7y ago
    > 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/
    • infecto 7y ago
      Oh wow new to me. Had not seen that one. Even more disappointing because the tool is far from primetime. Going back to the original. A few years back when I was using pipenv it kept the tagline that it was the future of python and endorsed fully but I am pretty sure that was a stretch or perhaps the maintainer was using his clout and his own recommendation.
    • jzl 7y ago
      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/
• ossworkerrights 7y ago
  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.
• jlg23 7y ago
  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 7y ago
    This has been a many-years long simmering issue.
• tus88 7y ago
  Grumpy old virtualenv user trying not to be smug.
• staticassertion 7y ago
  Not dead. https://github.com/pypa/pipenv/issues/4058#issuecomment-565550646 https://github.com/pypa/pipenv/issues/4058#issuecomment-5655...
  • jlv2 7y ago
    Not dead yet.
    • rolandog 7y ago
      Technically, that applies to everyone of us, and every product---or service---we use...
      • ben509 7y ago
        Technically, there is an infintesimal chance that entropy spontaneously reverses permanently and that nothing ever dies.
• specialist 7y ago
  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)
• darepublic 7y ago
  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.
• fulldecent2 7y ago
  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/CONTRIBUTING.md#release-process https://github.com/fulldecent/FDWaveformView/blob/master/CON... 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.
• manx 7y ago
  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.
• darepublic 7y ago
  If we aren't going to make the delivery deadline, just tell us.