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] |
Ideally, you'd have that "Continous Whatever" in your development, but somewhere between there and production, you want tests and/or other kind of auditing anyway.
Wanting "up-to-date, all the time" in production is asking for free lunch.
Of course, security issues have to be fixed, but usually, in production we have a different notion of "continuous", don't we?
| [reply] |
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.
I think you have your ups and downs reversed - easy to do if not used to the metaphor. NEILB has written quite a bit on this, see The River of CPAN for an introduction. There's been some work to mitigate the problem which you've highlighted but so long as there are dependencies it will never entirely vanish.
The point about Continuous Integration is that it requires 100% adherence to strict testing. This means that you have a build process which includes a full test cycle before the newest deps get anywhere near production. CI sounds good but it's a lot of work to get any robustness into it as hopefully should be obvious to most.
| [reply] |
| [reply] |