281–290 of 325 posts
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.
From the post itself, the symptom is: people are committing, but releases are not being made.
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.
Similarly, Slackware Linux's last stable release was 14.2, in June, 2016, but their -current release tree was last updated.... yesterday. Now, I could be super huffy that they haven't released in years, but this is open source software that I'm not paying for. Moreover, I have the power to choose multiple alternatives. I can run the -current release. I can make my own "pseudo-release" by just forking here and calling…
Earlier quoted context omitted.
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…
It seems that the choice is whether to live on the slightly-bleeding edge (as determined by “stable” releases, etc), or to live on the edge of end-of-life, always scrambling to rewrite things when the latest dependency library is being officially obsoleted. I advocate doing the former, while you seem to prefer the latter.
The problems with the former approach are obvious (and widely seen), but there are two problems with the latter approach, too: Firstly, you are always using very old software which are not using the latest techniques, or even reasonable techniques. This can even be considered to be bugs – like using MD5 hash for example, which, while being better than what preceded it, much software were using MD5 as a be-all-and-end-all hashing algorithm; this turned out later to be a mistake. The other problem is more subtle (and was more common in older times): It’s too easy to be seduced into freezing your own dependencies, even though they are officially unsupported and end-of-lifed. The rationalizations are numerous: “It’s stable, well-tested software”, “We can backport fixes ourselves, since there won’t be many bugs.” But of course, in doing this, you condemn your own software to a slow death.
One might think that doing the latter approach is the hard-nosed, pragmatic and responsible approach, but I think this is confusing something painful with something useful. I think that doing the former approach is more work and more pain from integration, and the latter approach is almost no work, since saying “no” to upgrades is easy. It feels like it’s good since working with an old system is painful, but I think one is fooling oneself into doing the easy thing while thinking it is the hard thing.
The other reason one might prefer the former approach to the latter is that by doing the former approach, software development in general will speed up by all the fast feedback cycles. It’s not a direct benefit; it’s more of an environmental thing which benefits the ecosystem. Doing the latter approach instead slows down all feedback cycles in all the affected software packages.
Of course, having good test coverage will also help enormously with doing the former approach.
Earlier quoted context omitted.
From the post itself, the symptom is: people are committing, but releases are not being made.
Remember that "releases" are a Github-specific feature, not a git one.
Earlier quoted context omitted.
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…
> 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. As someone who has had to deal with Python's packaging a lot, I would say that it's really, really bad. Maybe not the worst in the world, but it is much closer to the worst than to the best. There are 15 ways to package Python modules, none of which are feature complete (but a lot of the…
Earlier quoted context omitted.
I thought NPM was everyone's favourite hated package manager/repository?
The faults aren't so much with the actual NPM software as with the whole ecosystem. The real root of the problem IMO is that Javascript has such a tiny std lib compared to other popular languages that have package management systems. This encourages lots of people who are missing various functions normally found in std libs to write packages implementing various combinations of those functions. Those who are writing…
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…
Can you link to one of these times a maintainer said something like that?
I did some research and think this link is enough https://github.com/pypa/pipenv/issues/1137.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
> 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 should strive to never upgrade anything unless I absolutely must. It seems that the choice is whether to live on the slightly-bleeding edge (as determined by “stable” releases, etc), or to live on the edge of end-of-life, always scrambling to rewrite things when the latest dependency library is being officially obsoleted. I advocate doing the former, while you seem to prefer the latter. The problems with the form…
There is software out there that absolutely cannot break. Like "if this breaks, people will die". Medical software, power plant software, air traffic control software, these are obvious examples, but even trading and finance software falls into this category, if some hedge fund somewhere goes bankrupt because of a software bug real people suffer.
It doesn't matter how boring, inefficient and outdated these systems are. It doesn't matter how much pain they are to maintain and integrate. These are systems you do not fuck with. A lot of times people who do maintenance of these don't even fix known bugs in order to avoid introducing new ones and to avoid the rigorous compliance processes that has to be followed for every release. Updating the software just to bump up some related library to the latest version is simply not a thing in this context.
I am not working on anything like this. I work on a lighting automation system. If I fuck up my release, nobody is going to die (well, most likely, there are some scenarios), but if I fuck up sufficiently, a lot of people will be incredibly annoyed. So I have every version of every dependency frozen. All the way down the dependency tree. I do check for updates quite often and I make some effort to keep some things current, but some upgrades are simply too invasive to allow.
Earlier quoted context omitted.
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…
> 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. As someone who has had to deal with Python's packaging a lot, I would say that it's really, really bad. Maybe not the worst in the world, but it is much closer to the worst than to the best. There are 15 ways to package Python modules, none of which are feature complete (but a lot of the…
I was always impressed by CPAN compared to most other package managers I've used. And, yeah, between Python, Perl, Node, Ruby, and even PHP, Python is by far the most inscrutable and the most prone to giving me fits when existing Python apps like Lektor just... inexplicably break after one of the Homebrew versions of Python gets updated.