Serious question, what does pipenv (and poetry) have over conda?
A lockfile for consistent builds, that alone rules out Conda for a lot of serious things.
If this project is dead, just tell us
271–280 of 325 posts
Re: If this project is dead, just tell us
#272669 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.
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…
> The burden of figuring this all out lies with the visitor and is a annoying hassle.
I usually find it to be a much smaller hassle than recreating the functionality myself.
Re: If this project is dead, just tell us
#273Re: If this project is dead, just tell us
#274This "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…
Maintenance is something I've come to appreciate more and more every year. It's so easy to install dependencies, but it comes with a large hidden cost and painful lessons down the line.
Painful lessons, yes. Instant gratification versus long-term planning. I think this applies to more than just software.
Re: If this project is dead, just tell us
#275Earlier quoted context omitted.
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.
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?
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.
Re: If this project is dead, just tell us
#276669 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.
Clementine the music player is my go-to example of this phenomenon. Its got 750 commits in since its last release in 2016, there is regular merging, but the project management is in a place where trying to deploy builds to every platform is acting as a barrier to any new releases.
It recently finally merged its Qt5 support into master (which was in a working state since 2014) about two months ago. That might help the release process.
What doesn't help is that a consumer facing product of that scale is a nightmare to manage - it has over 2k open issues on Github but probably 95% of them are "I don't know how to do X" tech support kinds of things.
Re: If this project is dead, just tell us
#277Earlier quoted context omitted.
> The package which depends on the older version of libfoo is either dead, in which case you should stop using it, or it will soon be updated to use the newer version of libfoo So you are suggesting that every time libfoo bumps its version I have to update the dependencies on all of my projects to use the latest, find and fix all the incompatibilities, test, release and deploy a new version? Seriously?
Yeah, I mean what's the alternative? Your code will bit rot if you don't keep up. You don't have a living software project if you don't do this. You should read the release notes of the new version of your dependency, fix any obvious issues from that, see if your tests pass, and wait for bug reports to roll in for non-obvious things not caught by automated tests. Ideally you should do this before the new release of t…
> You don't have a living software project if you don't do this.
What I might have is a working piece of software that is an important part of company infrastructure. For mission critical software reliability is a much more important metric than being current. Unless there is some really compelling reason to update something it should not and will not get updated. There are mission critical services out there running on software that hasn't been changed in decades and that is a good thing.
> Also, your project should not demand a specific version of `libfoo`. If `libfoo` follows semver and a minor release breaks your project, that is a bug in `libfoo`.
Who the fuck cares if it is their bug or not? I need my service working, not play blame games. And if I have a well tested version deployed, why the hell would I want to fuck with that? And if I have tested my service when linked against libfoo 1.6.2.13.whatever2 I had better make sure that this is the version I have everywhere and that any new deployments I do come with this exact version.
But if I start a new project, I might want to use libfoo 3.14.15.whocares4 because it offers features X, Y and Z that I want to use.
Re: If this project is dead, just tell us
#278I 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…
You said the "project was shilled hard when it was first released". Why use a word with such strong conspiratorial connotations? Couldn't you just as easily argue that a lot attention was given to the project without implying that it was because of a shill conspiracy?
What concrete evidence leads you to the conclusion that coordinated shills are responsible for giving the project attention?
Re: If this project is dead, just tell us
#279Earlier quoted context omitted.
Yeah, I mean what's the alternative? Your code will bit rot if you don't keep up. You don't have a living software project if you don't do this. You should read the release notes of the new version of your dependency, fix any obvious issues from that, see if your tests pass, and wait for bug reports to roll in for non-obvious things not caught by automated tests. Ideally you should do this before the new release of t…
Exactly. This is what we signed up for when we release software and commit to keeping it maintained. This is what we do. If you instead just like writing software and throwing it over the wall/to the winds, you are an academian in an ivory tower, and have no connection to your users in the real world.
> you are an academian in an ivory tower, and have no connection to your users in the real world
Quite the opposite, actually. My responsibility is to my users. And that responsibility is to keep the software as stable as possible. So the only time I will consider upgrading my dependencies is when reliability requires it. If libfoo fixes some critical bug that affects my project, yes, maybe I should upgrade (although I am running the risk of introducing other regressions). If libfoo authors officially pronounce end of life for the version of libfoo I am using, maybe I should consider upgrading, even though it is safer to fork libfoo and maintain the well tested version myself. But it is irresponsible to introduce risk simply to keep up with the version drift. So if my project is used for anything important, I should strive to never upgrade anything unless I absolutely must.
Re: If this project is dead, just tell us
#280Earlier 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.
C/C++.
Conan is actually quite nice. I've been porting a series of projects to it and it's been a pleasant experience - Conan is very flexible, the documentation is thorough and the developers are very responsive on Slack/GitHub.
https://conan.io/