Is there a reason why mkc only caches extension releases and not extensions pinned with a SHA? E.g.:
"arcade-tile-util": "github:microsoft/arcade-tile-util#v1.0.1",
"ColorBlock": "github:UnsignedArduino/ColorBlock#ac7b9500e40045cf1ddd8c5b7481d11bcb317f5f",
arcade-tile-util will get cached by mkc but ColorBlock never gets cached as it isn’t a release and will be downloaded every build. Was this a specific decision to be made against or could it be implemented? (It seems like it would require modifying the lines around here in the microsoft/pxt repo, so that seems harder then just sending a PR to microsoft/pxt-mkc? But I do see some semi-related issues in the pxt-mkc repo, any ideas?)
No reason comes to mind that we wouldn’t cache shas beyond that it’s just not implemented currently, it’s as specific as a tag anyways. That said the preferred behavior will always be to just use tags in the first place, we can look at bug fixes sure but there’s only very narrow reasons to actually be using an extension without one (e.g. testing an unreleased version / etc)
1 Like
I think if you import a MakeCode Arcade extension into a game that doesn’t have a release tag, it just grabs and pins to the latest commit at that time - I don’t know how many extensions don’t have release tags.
It does, we prioritize projects continuing to work, so pinning as narrowly as we can makes it so e.g. people don’t accidentally change a blocks shape and break everyone elses projects next time they run the code.
(But what I meant more is that typically the people using an extension that don’t have a tag are either the person themselves (who should make a tag for it) or someone that knows them fairly directly to have learned about it (who should tell the person to make a tag). We don’t typically approve extensions without a tag (unless we miss it accidentally, which may have happened but rare))
2 Likes