Open Bug 1741960 Opened 4 years ago Updated 4 years ago

Internally manage MSYS tools on Windows

Categories

(Firefox Build System :: Mach Core, enhancement, P3)

Product:
Firefox Build System
Component:
Mach Core
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: mhentges, Unassigned)

References

Details

(this is a discussion ticket about a potential future for MozillaBuild).

Rather than having Windows developers have to install the MozillaBuild environment and keep it up-to-date, we should have Mach automatically fetch the tools it needs.

We can either internally manage an MSYS2 environment and fetch packages with pacman, or we can utilize our existing "toolchain artifact" infrastructure and redistribute MSYS2 packages (we'll need to verify that this is OK with the licenses of the packages we're redistributing, of course).

See Also: → 1740123
Priority: -- → P3

Where do I +100 this? I really don't want to think what do I need to update and when. Question though, with a new install of Windows I will still need to install Python first in order to run Mach?

Where do I +100 this?

Hah, I like your attitude :P

Question though, with a new install of Windows I will still need to install Python first in order to run Mach?

I'm guessing that bootstrapping a new Windows machine will look like this:

  1. <Install your tools: IDE, diff tool, etc>
  2. Install Python
  3. Unsure the exact details here, but hg needs to be installed - perhaps our standalone bootstrap script can set it up
  4. Run the standalone bootstrap script, then have Mach automatically bootstrap all the other pieces it needs.

I really, really don't want my build shell env to be automagically updated. Stability is a virtue for tooling, especially configurable tooling. Let me choose when to update.

I last updated mozilla-build on this machine in March 2020, and that's a great thing for me as a dev. To that end, be really really aware of how much auto-updating would really buy our devs. Right now I update mozilla-build about yearly, and it barely takes minutes to download and install a new version. Let's be realistic about how much time this would save, if this were more automatic: https://xkcd.com/1205/ :)

Also, in particular mach has had some issues recently, such as handling of git-worktrees with python virtual envs. Let's avoid situations where devs avoid fetching central because of breakage. The more things that we can start "assuming" because we can "just auto-download tools" generally risks fragility, and slowly locks out workflows not 100% supported by the system. (which is bad for dev productivity)

For example, some of us have half a dozen machines (e.g. my hardware-accelerated graphics development). To avoid issues, simplicity is preferable to magic.

The bootstrapping process already causes over-aggressive downloading, making it harder to use in bandwidth-constrained (tethering!) or offline (planes!) scenarios.

I like the msys2 package idea, though!
But frankly I think MozillaBuild is in an amazing place right now, and I'd definitely prefer no-change to change here.

I believe this is not about globally changing shell env but just for mach's internal usage. Opting out autoupdate sounds good, though.

I believe this is not about globally changing shell env but just for mach's internal usage. Opting out autoupdate sounds good, though.

Exactly, this is correct.

  • The pieces of MozillaBuild would not be affected by Mach when it fetches and internally uses the tools it needs
  • Just like for downstream Linux distros, it'd be possible to manually manage build dependencies

To that end, be really really aware of how much auto-updating would really buy our devs

I don't understand this sentence, I think "buy" is a typo - I don't know which word it's replacing, though :)
Ah, re-reading this, I see now that the interpretation is: "be aware of how much value would be provided to devs by implementing auto-updating".

Right now I update mozilla-build about yearly, and it barely takes minutes to download and install a new version. Let's be realistic about how much time this would save, if this were more automatic: https://xkcd.com/1205/ :)

Though this saves the amount of time developers spend downloading and updating MozillaBuild, keep in mind that this effort is implicitly allocated elsewhere:

  • There's additional lag when the build team works to leverage features/performance/bugfixes in new dependency versions, because rather than "just bumping the dep", we have to release a new MozillaBuild, at which point it takes time to propagate to devs. We do still need to support the "old dependency" versions, but the "general case" of developers, they don't benefit from the new version until far later.
  • More resources have to be committed by the build team when supporting a dev to resolve a local problem. Being able to wave away a whole class of potential failures because dependency versions are pinned is a major benefit.
    • Considering the lack of resources on the tools team right now, the hours poured into support seriously cut back the amount of improvements we can do.

Also, in particular mach has had some issues recently, such as handling of git-worktrees with python virtual envs. Let's avoid situations where devs avoid fetching central because of breakage.

I'm assuming you're referring to this bug.
This is tough, and there's only a few ways to avoid the issues here:

  1. Don't perform improvements that carry risk of regression: this leaves us in a case where the faults of the build system restrict us from making serious improvements - if we aren't able to address structural flaws, then we're going to have more critical problems in the future
  2. Just don't write bugs 😉: if the build team was in the state it was three years ago, this situation would be less likely because of the amount of experience around potential regressions was so much higher. However, we lost the majority of our "heavy hitters" in 2020, and my foresight isn't (yet?) as strong as theirs were.

The more things that we can start "assuming" because we can "just auto-download tools" generally risks fragility

I'd flip this around and say that cargo is a fantastic example of a tool that "auto-downloads" and auto-builds the pieces you need, and it generally "just works". If you had to manually compile each crate you depended on and manually wire it together, it would be far more error-prone, especially at the intermediate-level of software experience.

and slowly locks out workflows not 100% supported by the system. (which is bad for dev productivity)

Note that due to downstream constraints such as Linux distros, we will always need to support non-auto-bootstrapped tools.
The goal of this bug is to improve the experience of the "general" developer, but we won't be closing the "non-auto-bootstrap" use case anytime soon.

The bootstrapping process already causes over-aggressive downloading, making it harder to use in bandwidth-constrained (tethering!) or offline (planes!) scenarios.

True, there's probably efficiency improvements that can be made.
I would say that in recent years there's a more "download-happy" consensus, especially with the advent of "pinned/locked" dependencies. However, I think this is a great thing - removing a whole class of "dependency mismatch" bugs is a huge boon to stability and support costs.
(Of course, this is still referring to the "general case" - in the separate use-case of "build using the manually-set-up dependencies I have on my machine", the situation is essentially unchanged).

I like the msys2 package idea, though!

💪

But frankly I think MozillaBuild is in an amazing place right now, and I'd definitely prefer no-change to change here.

This might be the origin of where our stances differ here. From my perspective, I see that MozillaBuild is in drastic need of improvement:

  • ./mach try fuzzy breaks copy-paste until you restart the terminal
  • CTRL-C sometimes kills the wrong process and breaks output
  • The terminal doesn't always close when you exit
  • hg doesn't work interactively (e.g.: hg histedit)
  • Colours don't work consistently (./mach build warnings, etc)
  • python3 -m venv doesn't work, so you can't use pipx, etc
  • Packages inside of MozillaBuild are out-of-date (e.g. Python), can only be updated by having a new MozillaBuild release deployed
  • <more that I don't know off the top of my head>

To me, the costs of these issues dramatically outweighs the "risk of change" when we endeavour to fix them.

You need to log in before you can comment on or make changes to this bug.