A software abomination for y'all
-
@dkf said in A software abomination for y'all:
It works well provided your CI workflows are not totally worthless.
Well that won't do it.
-
@dkf said in A software abomination for y'all:
It works well
provided your CI workflows are not totally worthless.
-
@boomzilla said in A software abomination for y'all:
@Gribnit said in A software abomination for y'all:
Because
IC developmentCSS is now so complex that human beings literally cannot lay them out manually and have not been able to for decades.
I'm in this post, and I don't like it.
(My team "switched" to a CSS-in-JS library about a year ago. "Switched" because it's mostly just for new code; bringing old code up to snuff is done as a catch-as-catch-can basis, which means that maybe 50% of the site is still running on vanilla CSS, unvisited by even LESS or SASS.)
-
@Gąska said in A software abomination for y'all:
or as we say in Poland,
złej baletnicy majtki w dupę wchodzą.kurwa
-
@dkf said in A software abomination for y'all:
It works well provided your CI workflows are not totally worthless.
Well, this is what I struggle to get into management's head every day. Dependency management has the following subtasks:
- Identify dependencies
- Be aware of when dependencies are updated.
- Integrate dependency updates into main product.
Plenty of tools are available. These tools concentrate on #2. If you work from one ecosystem, it's possible to completely cover #1 and #2 without any effort. But, as soon as someone brings in "random widget library XYZ" because "it's awesome", #1 may become manual and maybe #2 will acquire some manual steps.
You are still on your own for #3. Good automated testing is the key to making #3 tolerable. For an organization that updates their dependencies often, automated tested is a huge timesaver and is done without any prompting.
However, organizations that have a large codebase that was built by amateurs will spend 90% of their time on #3 because testing is an absolute nightmare for them. The past result was that they simply never updated anything. The world has changed to the point where many of these organization now have to fix their dependencies in a short timeframe. They shop for a tool, and are disappointed that the tool does little other than create a huge backlog of "hey, there's an update you have to handle" events that go ignored.
-
@Jaime said in A software abomination for y'all:
They shop for a tool, and are disappointed that the tool does little other than create a huge backlog of "hey, there's an update you have to handle" events that go ignored.
Dependabot's really easy (once you've built the description of dependencies properly in the first place and written the config file). It's mostly a matter of giving the issues it files a quick eyeball to see if they look reasonable and, if they do, commenting on the issue
@dependabot merge, after which the bot will do its work provided your CI tests pass. An absolute minimum of testing would be to check everything out and at least check that it builds; without at least that, you've not got an auto-commit gate worth a damn. Having actual tests as well is a bonus.Alas, we can't use it for our Python code. That deliberately uses a more complex scheme for versioning because it has to support many different versions of the base runtime, and that is in turn because our users are using many different versions (alas). However, the resulting dependencies are either not in need of dependabot's help or are beyond what it can handle. If we used tight version binding we could… but we don't. Note that there's definitely some critical libraries that there's no one version that works with all the versions of Python we support, but we need numpy and scipy anyway so we put up with their BS (and aren't using the features that change much between versions other than “works with version 3.x of Python”).
Still, things aren't onerous. Some of our stuff can (and should!) use dependabot, and I've got it configured to check only every week.
-
@dkf said in A software abomination for y'all:
after which the bot will do its work provided your CI tests pass
That's my point. The people who need dependabot are mature organization that are rolling-their-own and can save some time and get a better product. The people who are really excited about dependabot have nothing except a shaky application and a regulation to comply with. The latter group will get almost zero benefit from it.
-
@Jaime said in A software abomination for y'all:
The people who need dependabot are mature organization that are rolling-their-own and
If they're truly rolling their own, they're already fucked. Nobody will be able to help them because what they've got will not conform to anything that anyone else understands. The first requirement for using dependabot is that you're using one (or more) of a small set of package ecosystems, and those include enough information that the bot can determine what is being used (and scan public package repos to find what is out of date). Without that, you can't get suggestions to start with.
But if you want to evaluate how good its suggestions are, you need more. Sometimes a dependency change is straight forward, sometimes it needs you to tweak things a bit (e.g., if one function out of thousands has been modified slightly incompatibly and you happened to be using it in a small number of places, generally pretty easy to adapt to, but more than what the bot can do for you), and sometimes there's just no way to adapt without major work and you have to note that this is an area that will need major attention. (Had one of those last week, where a security delegation library was updated by four major versions since we coded against it. We'll need to redevelop that module of our code to make that version jump, or maybe we'll just drop support for that feature entirely as it turns out that it's not actually being used so far as anyone can tell. In any case, no bot can figure that out for us!) Sorting even an initial assessment of this stuff out requires some sort of build-and-test regime; that's what using CI is absolutely intended for.
If the code don't build, you know not to merge. And the bot is obviously stupid, but that's OK. It's not being used for being smart, but rather for being a robotic assistant that deals with some of the worst aspects of versioning drudgery.
-
@dkf The F500 (100?) I'm at uses Whitesource, mostly.
-
