I hadn't thought of the consequences of someone removing an open source Perl module on which one of mine depends, but I *guess* it *could* happen
That'd never been of concern to me either. For one thing, perl isn't (as) vulnerable to that because perl modules get installed locally rather than downloaded from their source, on demand, each time they are used as so much JS stuff is.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
And there's minicpan and pinto, probably others.
I think (perhaps fancy) the habit of having
local mirrors of the repository
is more common among Perlers than with users of other languages
On the other side, a search for "npm local repository"
(google, ddg) shows
interesting
items
that seem to exist longer than the few days since
the incident, probably they get more traction now … :-)
But perhaps we should replace "Yes, even you can use CPAN" with "UTSL", anyway :->
| [reply] |
On the other side, a search for "npm local repository" (google, ddg) shows interesting items that seem to exist longer than the few days since the incident, probably they get more traction now … :-)
Possibly. But that raises another potential issue that arises from the latest, greatest buzzword fad that's been all over the IT news of late, and comes under various names: Continuous Life Cycle; Continuous Integration; DevOPs; Continuous Delivery etc.
A big part of this, as evidenced here and elsewhere, is the idea that every project automatically incorporates every change from all its dependencies several times a day.
To me, this is total insanity. And I am quite sure that history will prove me right again.
In theory, the idea of having "everything, up-to-date, all the time" sounds wonderful. Until you do the math.
You take a smallish project with say a dozen dependencies; each of which has half-a-dozen dependencies; each of which has 2 or 3.
Someone way down stream publishes a change that breaks something (or several somethings) higher up in a subtle way; the upstreamers go into frantic overload to write workarounds and publish; their upstreamers do the same; and your project falls in a heap because of it.
Now the developer of the breaking change realises his mistake -- whether through his own processes or because he took heat from a few dozen of his upstreamers -- and backs out the change; and so the whole chain reaction fires again.
I'm not a mathematician, and I know little about Chaos Theory beyond its name; but the above scenario seems as good a real-world definition of it as a layman could hope to find.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
| [reply] |
