Native toolset bootstrapping design

[chcosta]

Implementation design for #129

[JohnTortugo]

I am curious about some points. I don't know if this was discussed before. Sorry, if it was.

• Do we need to keep .zip and .tar versions of the the same libraries/packages/* ? Will that be specified?

• Can't we settle on just one scripting language for these automation scripts? That is, instead of having .ps1/.bat and .sh versions of many(all) scripts, can't we just have one .py script? What are the benefits of duplicating these scripts instead of using some other portable scripting language?

• This is actually a suggestion: I think it might be interesting to have a "latest" file version for the packages/assets/libraries/etc. By that I mean having, for instance, a python-latest-embed-amd64.zip file available, besides "python-3.6.5-embed-amd64.zip, python-3.7.0b3-embed-win32.zip, etc.."; the benefit that I imagine is to let users automatically fetch the latest version of a file without having to change any configuration file.

[chcosta]

Thanks for the feedback @JohnTortugo

Do we need to keep .zip and .tar versions of the the same libraries/packages/* ?

I'm not certain I understand exactly what you're asking. zips and tars would be archived as needed per platform distribution.

Can't we settle on just one scripting language for these automation scripts?

Is Python inbox on every supported platform? If not, it becomes a native toolset bootstrapping problem and you would need Python to bootstrap Python.

I think it might be interesting to have a "latest" file version

I've considered that, but I couldn't come up with a scenario where that was actually useful. Do you have a concrete scenario? In general I'd expect that repo's want to be explicit about their dependencies.

[alexperovich]

Is Python inbox on every supported platform? If not, it becomes a native toolset bootstrapping problem and you would need Python to bootstrap Python.

Any helix client will have python 2.7 on it. With VSTS "bring your own cloud" that would mean that any build agent running in helix would have python also. That just leaves the local dev scenario.

If a specific distro doesn't have python on it then we would have to build binaries from source, but helix would have this issue also.

[JohnTortugo]

Is Python inbox on every supported platform?

I don't think so. I was thinking that having only install-python.ps1 and install-python.sh would be better than duplicating all scripts. By the way, Python was just an example, I am just curious which other options were considered.

Do you have a concrete scenario?

I don't have an specific case in mind, but I think anyone interested in just using the latest version of an library/tool should be able to. That also doesn't sound like a seldom thing.

[chcosta]

I was thinking that having only install-python.ps1 and install-python.sh would be better than duplicating all scripts.

I don't entirely disagree.

The other primary option that was considered was Powershell Core, but that option doesn't work on every platform.

[weshaggard]

This has been discussed many times (one example #71) and it always boils down to we need to depend on something that is on the system and doesn't require bootstrapping and the goal is to minimize the amount of code we write in a scripting language and get into our build engine as fast as possible.

[weshaggard]

This is actually a suggestion: I think it might be interesting to have a "latest" file version for the packages/assets/libraries/et

While that might seem nice for some scenarios I think we should try to avoid it as long as possible because it only leads to difficulties. Depending on the latest version of something means we don't have deterministic builds over time which leads to various issues, particularly on the reliability front.

[tmat]

👍