Skip to content

Conversation

@SinisterRectus
Copy link
Member

No description provided.

@truemedian
Copy link
Member

truemedian commented Feb 7, 2025

Some consideration should be applied that this change will cause anyone using get-lit with the $LUVI_VERSION environment variable less than 2.15.0 (such as potentially in automated testing or likewise) to suddenly start failing.

@SinisterRectus
Copy link
Member Author

Is it enough to just make the url conditional then?

@truemedian
Copy link
Member

I believe so? Nothing else here should be breaking with this change

@SinisterRectus
Copy link
Member Author

Sounds good, except I'm too lazy to write logic for semver comparisons in languages that I don't know. I'll change this to a draft for now.

@SinisterRectus SinisterRectus marked this pull request as draft February 7, 2025 20:18
@Bilal2453
Copy link
Contributor

A pure sh semver comparison is going to be annoying. The easiest way is to depend on gnu coreutils such as sort -V. should be fine.

@SinisterRectus
Copy link
Member Author

Alternatively, the script can fallback to the old url format if the new one fails.

@truemedian
Copy link
Member

Honestly this change is also a pretty good chance for us to rework how this works in the first place, what are thoughts on creating a new repository that packages releases for luvi+lit+luvit all in one .tar.xz or .zip.

Then git-lit can be simplified to a single download + extract and we completely bypass handling any weird edge cases like how to handle one download failing and one succeeding.

@Bilal2453
Copy link
Contributor

Sounds good, but do we need a new repo for that? I feel like a number of existing repos can already fulfill that.
Would also be neat if the action automatically triggers on releases/tag creation

@SinisterRectus
Copy link
Member Author

My only hesitation to providing prebuilt luvit and lit binaries is that this opposes our message that luvi apps are supposed to be easy to build on the fly. It is convenient, though, so I support it overall. I do not have an opinion on how they are hosted.

@SinisterRectus SinisterRectus mentioned this pull request May 29, 2025
@truemedian
Copy link
Member

truemedian commented Jun 3, 2025

I've been side tracked doing other things so I don't think I'll get around to finishing up an improved get-lit script anytime soon. I say it's probably reasonable to pull the trigger on this and merge it and deal with any side effects if they pop up.

If someone really wants to use the old get-lit there's nothing preventing them from using an older version of the script using a specific commit instead of master.

This isn't a perfect solution, but it is a solution and introduces the newest luvi and lit into the ecosystem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants