<div dir="ltr">Hi,<div><br></div><div>We can discuss Horizon v next today during our mid-cycle call: <a href="http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016346.html">http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016346.html</a></div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,<br>Ivan Kolodyazhny,<br><a href="http://blog.e0ne.info/" target="_blank">http://blog.e0ne.info/</a></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 28, 2020 at 5:03 PM Peter Pentchev <<a href="mailto:roam@ringlet.net">roam@ringlet.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jun 24, 2020 at 02:07:06PM +1200, Adrian Turjak wrote:<br>
> On 24/06/20 1:05 am, Thomas Goirand wrote:<br>
> > Anyone dismissing how huge of a problem this is, isn't doing serious<br>
> > programming, for serious production use. That person would just be doing<br>
> > script kiddy work in the playground. Yes, it works, yes, it's shiny and<br>
> > all. The upstream code may even be super nice, well written and all. But<br>
> > it's *NOT* serious to put such JS bundling approach in production.<br>
> And yet people are running huge projects in production like this just<br>
> fine. So clearly people are finding sane practices around it that give<br>
> them enough security to feel safe that don't involve packaging each npm<br>
> requirement as an OS package. How exactly are all the huge powerhouses<br>
> doing it then when most of the internet's front end is giant js bundles<br>
> built from npm dependencies? How does gitlab do it for their omnibus?<br>
> From a cursory glance it did seem like they did use npm, and had a rake<br>
> job to compile the js. Gitlab most definitely isn't "script kiddy work".<br>
> <br>
> I'm mostly a python dev, so I don't deal with npm often. When it comes<br>
> to python though, other than underlying OS packages for python/pip<br>
> itself, I use pip for installing my versions (in a venv or container).<br>
> I've had too many painful cases of weird OS package versions, and I<br>
> dislike the idea of relying on the OS when there is a perfectly valid<br>
> and working package management system for my application requirements. I<br>
> can audit the versions installed against known CVEs, and because I<br>
> control the requirements, I can ensure I'm never using out of date<br>
> libraries.<br>
> <br>
> Javascript and npm is only different because the sheer number of<br>
> dependencies. Which is terrifying, don't get me wrong, but you can lock<br>
> versions, you can audit them against CVEs, you can be warned if they are<br>
> out of date. How other than by sheer scale is it really worse than pip<br>
> if you follow some standards and a consistent process?<br>
<br>
What Thomas is trying to say, and I think other people in this thread<br>
also agreed with, is that it's not "only" because of the sheer number of<br>
dependencies. My personal opinion is that the Javascript ecosystem is<br>
currently where Perl/CPAN was 25 years ago, Python was between 15 and 20<br>
years ago, and Ruby was 10-15 years ago: quite popular, attracting many<br>
people who "just want to write a couple of lines of code to solve this<br>
simple task", and, as a very logical consequence, full of small<br>
libraries that various people developed to fix their own itches and just<br>
released out into the wild without very much thought of long-term<br>
maintenance. Now, this has several consequences (most of them have been<br>
pointed out already):<br>
<br>
- there are many (not all, but many) developers who do not even try to<br>
  keep their own libraries backwards-compatible<br>
<br>
- there are many (not all, but many) developers who, once they have<br>
  written a piece of code that uses three libraries from other people,<br>
  do not really bother to follow the development of those libraries and<br>
  try to make their own piece of code compatible with their new versions<br>
  (this holds even more if there are not three, but fifteen libraries<br>
  from other people; it can be a bit hard to keep up with them all if<br>
  their authors do not care about API stability)<br>
<br>
- there are many libraries that lock the versions of their dependencies,<br>
  thus bringing back what was once known as "DLL hell", over and over<br>
  and over again (and yes, this happens in other languages, too)<br>
<br>
- there are many, many, *many* libraries that solve the same problems<br>
  over and over again in subtly different ways, either because their<br>
  authors were not aware of the other implementations or because said<br>
  other implementations could not exactly scratch the author's itch and<br>
  it was easier to write their own instead of spend some more time<br>
  trying to adapt the other one and propose changes to its author<br>
  (and, yes, I myself have been guilty of this in C, Perl, and Python<br>
  projects in the past; NIH is a very, very easy slope to slide down<br>
  along)<br>
<br>
I *think* that, with time, many Javascript developers will realize that<br>
this situation is unsustainable in the long term, and, one by one, they<br>
will start doing what C/C++, Perl, Python, and Ruby people have been<br>
doing for some time now:<br>
<br>
- start thinking about backwards compatibility, think really hard before<br>
  making an incompatible change and, if they really have to, use<br>
  something like semantic versioning (not necessarily exactly semver,<br>
  but something similar) to signal the API breakage<br>
<br>
- once the authors of the libraries they depend on start doing this,<br>
  start encoding loose version requirements (not strictly pinned), such<br>
  as "dep >= 1.2.1, dep < 3". This is already done in many Python<br>
  packages, and OpenStack's upper-constraints machinery is a wonderful<br>
  example of how this can be maintained in a conservative manner that<br>
  virtually guarantees that the end result will work.<br>
<br>
- start wondering whether it is really worth it to maintain their own<br>
  pet implementation instead of extending a more-widely-used one, thus<br>
  eventually having the community settle on a well-known set of<br>
  more-or-less comprehensive and very widely tested packages for most<br>
  tasks. Once this happens, the authors of these widely-used libraries<br>
  absolutely *have* to keep some degree of backwards compatibility and<br>
  some kind of reasonable versioning scheme to signal changes.<br>
<br>
So, I'm kind of optimistic and I believe that, with time, the Javascript<br>
ecosystem will become better. Unfortunately, this process has taken many<br>
years for the other languages I've mentioned, and is not really fully<br>
complete in any of them: any module repository has its share of<br>
mostly-maintained reimplementations of various shapes and sizes of the<br>
wheel. So I guess the point of all this was mostly to explain the<br>
problem (once again) more than propose any short-term solutions :/<br>
<br>
G'luck,<br>
Peter<br>
<br>
-- <br>
Peter Pentchev  <a href="mailto:roam@ringlet.net" target="_blank">roam@ringlet.net</a> <a href="mailto:roam@debian.org" target="_blank">roam@debian.org</a> <a href="mailto:pp@storpool.com" target="_blank">pp@storpool.com</a><br>
PGP key:        <a href="http://people.FreeBSD.org/~roam/roam.key.asc" rel="noreferrer" target="_blank">http://people.FreeBSD.org/~roam/roam.key.asc</a><br>
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13<br>
</blockquote></div>