Hi,
On Fri, 2020-10-16 at 17:00 +0000, Benjamin Schubert wrote:
> Hey,
>
> Responses inline
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Wednesday, October 14th, 2020 at 11:45 AM, Tristan Van Berkom
> <[email protected]> wrote:
>
> > Hi,
> >
> > On Fri, 2020-10-09 at 14:24 +0000,
> >
> > Benjamin Schubert wrote:
> >
> > > Hey everyone,
> > >
> > > TLDR: I would like a way of allowing network access during builds on a
> > > per-element basis, to ease transition into BuildStream.
> > >
> > > I realize this has a potential to be highly controversial, but I think
> > > that
> > > the benefits in terms of ease of adoption makes it worth it.
> >
> > In my opinion, this has the potential to cause more harm than good.
> > A good question is, if you are going to poke holes in the sandbox and
> > allow network access, what's the point of using BuildStream at all ?
>
> The point is about being able to incrementally improve the way your builds are
> made. It can be extremely hard, or too costly for a company to move everything
> to a 'correct' point before being able to move to BuildStream.
>
> This opens more an easy adoption of BuildStream, by allowing most of the
> benefits of it, and allowing to improve the 'bad' elements later, rather than
> having a way of solving every problem before moving to it.
>
> For me, this is a key point that BuildStream offered, compared to, for
> example,
> Bazel, which is more or less 'all or nothing'.
>
> Yes, having network access during your builds can be bad, and we should
> absolutely discourage that. However, I strongly believe that in order to help
> with adoption, users should be allowed to explicitely ask the permission to
> shoot themselves in the foot.
I'm not trying to block this outright, but still want to caution that
this really might do more harm than it does good.
Also, I would be more interested to see examples which are specifically
difficult to deal with, and work on making those use cases easier to
deal with.
This is after all why we developed plugins like the cargo plugin for
rust apps (some weird languages want to download dependencies from the
internet) - if we can write source plugins for these problematic
languages, this is a better avenue to pursue than to just give up and
open up the network at build time.
Do we have concrete examples of workflows which are difficult to port
which cannot be solved with source plugins we can write ?
[...]
> > If network access were "supported", this could lead us down a road
> > where we are requested to rebuild things when artifacts are too old
> > (for instance, I cannot build against this dependency, because the
> > random source code it downloaded from the internet only 3 months ago is
> > no longer valid for me to build against).
>
> Again, if you download from the internet that is a problem. If you have
> already
> a cache for such dependencies in your organization, that is not a concern.
I think the above is dangerous thinking, and there are certainly still
concerns.
Just because you are maintaining a store of sources in your own
organization does not really mean that those sources are not random,
and while it might work for a time (or even forever, if you are very
careful to always use it correctly), it will be difficult to maintain
and guarantee correctness of your builds over longer periods of time.
Essentially, this externalizes the problem of matching up a specific
set of inputs with a given build, making it the organizations problem
instead of using BuildStream to specifically address all inputs (with
checksums or git shas or the like)... I can see this being a cause of
frustration years down the line.
For instance, every few years when you fork your codebase for the next
generation model of your appliance, and you want to use a whole new set
of dependencies to build your new generation software against, then it
is up to you have separate caches for these deterministically stored
dependencies on your internal servers, it is fairly easy to screw up
and forget that you might have to land a hotfix for an older model that
is still supported in the field, and not be able to because you
"upgraded" you organizations dependency cache...
While this example applies over time, it also applies to building
products and appliances for different markets and clients, the
differing variants of your product may end up using differing versions
of the sources you host in an internal store, and you will need to
manually fork that internal store every time you fork the BuildStream
project(s) which builds your product.
This margin of error can be eliminated by ensuring that your
BuildStream project data addresses sources specifically and does not
tolerate variants (like tarball address without checksum for instance).
> > Mostly I worry that if we give users any opportunity to allow internet
> > access in builds, we almost guarantee that they will not do the minimal
> > legwork required to ensure their build works without network access.
>
> I believe that this is to the users to decide. We can make it very clear
> in the docs that this is a bad idea, and users can decide to shoot themselves
> in the foot.
>
[...]
> No, again, this is a documentation concern. We can document that by using this
> you understand your element is not repeatable etc.
>
> Fixing 'one element' is something that is doable indeed. Doing that at a
> company scale, on large projects become extremely hard. Being able to move to
> BuildStream before, allows to stop the bleeding for new elements and cleanup
> the rest on a longer term.
I am worried about underestimating the willingness of users to not fix
a problem when given any opportunity, I expect that given a simple
switch, people will always turn it on at any time any element gives
them trouble even if it was relatively easy to fix, and they will not
circle back to fix this problem element until it has hurt them, twice.
Regardless of whether we warned users in advance, they would be right
to blame us for not forcing them to do a small amount of work in
advance and save them from possible problems down the line.
In conclusion, these are my general feelings on the matter:
* If there are cases I've overlooked where a "source transform"
would not remedy the situation, then maybe we need a switch
like you suggest, but I'd really like to be enlightened as to
what those cases are.
* Right now we only have "source transforms" for python and rust
(the pip and the cargo sources).
This is a sad state of affairs, there are probably some other
weird languages doing similar things, node.js comes to mind.
Is it realistic for us to be able to cover every language which
downloads external dependencies from the internet at build time
with a source plugin (like pip/cargo) that we maintain in our
trusted plugin collection ?
I feel like this is realistic, but if not, then maybe it also
calls for such a switch.
* There are some cases which are ridiculously easy to fix, like
scripts which want to download config.sub and config.guess from
git.savannah.gnu.org (which sometimes need to be fixed to copy them
in from /usr/share/automake/ instead), or builds like cracklib
which might want to download it's word dictionary if the user
forgot to separately put it in place.
In these cases, I worry that providing a switch is going to
result in most of these easy to fix issues being completely
ignored and worked around, leading to a generally bad user
experience down the road.
Cheers,
-Tristan
