Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider to bundle the runtime #61

Open
probonopd opened this issue Aug 5, 2024 · 9 comments
Open

Consider to bundle the runtime #61

probonopd opened this issue Aug 5, 2024 · 9 comments

Comments

@probonopd
Copy link
Member

The downloading mechanism is not robust over time:

  • The runtime repo name might change
  • The runtime filename might change

Errors caused by this should happen at build time, when developers can fix it, rather than at run time, when users are affected.

Hence we should consider to bundle the runtime in the appimagetool AppImage.

But the bare minimum needed, I think, is that changes in type2-runtime need to trigger a build of appimagetool. So that any potential issues are seen by developers immediately.

@TheAssassin
Copy link
Member

In either case, you'd need to touch the build system. But then again, there is no reason not to keep those stable.

@TheAssassin
Copy link
Member

But the bare minimum needed, I think, is that changes in type2-runtime need to trigger a build of appimagetool. So that any potential issues are seen by developers immediately.

I've replied to that in the other issue. I won't copy-paste it.

@probonopd
Copy link
Member Author

probonopd commented Aug 5, 2024

The runtime repo name might change

E.g., if we call "type" "version" one day, as we had brainstormed at some point in time.

The runtime filename might change

As evidenced today.

When either happens, an older appimagetool will no longer work.
This just seems way too fragile for me.

Would it be OK for you to bundle at least default or fallback versions? If I think about it, since an AppImage is supposed to have no dependencies other than what comes with the operating system, I think that's the only way to be in line with our "one app = one file" mantra.

@TheAssassin
Copy link
Member

As evidenced today.

By accident or so. Not by intention. It's been fixed.

@TheAssassin
Copy link
Member

TheAssassin commented Aug 5, 2024

When either happens, an older appimagetool will no longer work.
This just seems way too fragile for me.

Just make releases and reference a specific release from appimagetool.

Running cutting edge will lead to problems.

@probonopd
Copy link
Member Author

Then

  • Someone would need to take time to make releases (you know that I don't like this burden)
  • People would expect the releases to be maintained (also the older ones)
  • We would have to store and host all old runtime releases forever (or old versions of appimagetool would break)
  • The advantage of downloading always the latest runtime would be negated - we could just bundle runtimes with the same effect
  • And we could still not easily switch e.g., from GitHub to somewhere else, should it ever be needed.

For these reasons I really think the runtime needs to be bundled.

@probonopd
Copy link
Member Author

By accident or so. Not by intention. It's been fixed.

Can happen anytime again. In fact, will happen again - only a matter of time.

@TheAssassin
Copy link
Member

Someone would need to take time to make releases (you know that I don't like this burden)

We've agreed to do those more than once because they make sense and I think you should remember at least that. Nobody likes doing it, but it's a sign of project maturity. People use these tools and the runtime every day.

People would expect the releases to be maintained (also the older ones)

Nope. Nobody needs to maintain old releases. They should not be deleted. But every project has a reasonable support policy. If the policy is "we don't support anything but latest", then that's fine. If it's broken, go update first, then retry.

We would have to store and host all old runtime releases forever (or old versions of appimagetool would break)

Not necessarily. People can be forced to update their tooling occasionally. Plus, hosting on GitHub is free.

The advantage of downloading always the latest runtime would be negated - we could just bundle runtimes with the same effect

True. I'd prefer to download the latest version by default. But then again, downloading allows for implementing all kinds of varieties: downloading latest continuous release, downloading latest stable release, downloading a specific version, ... It just automates the step of downloading the runtime.

In my opinion, it wouldn't be a big deal if people just had to download the runtime anyway. Then, you don't have any responsibility on which versions they use. However, that's a big usability downside. But, then again, that's how all the other solutions work: you need to specify versions somewhere.

And we could still not easily switch e.g., from GitHub to somewhere else, should it ever be needed.

I've proposed a specific download API that we control since I think as early as 2018. You're not a fan of hosting this yourself, though. This would give us control however.

As said, depending on the support policy, we could introduce such breaking changes anyway.

For these reasons I really think the runtime needs to be bundled.

I'll think about bundling them again. But I have so many good reasons not to do so. And we've talked about all of them. I'm not 100% happy with the downloading either, but then again, it's working just fine for so many people and it's way better than all previous attempts.

In any case, you wouldn't want to automatically fall back to some old specific version. What if that one's inherently broken? Or maybe a security fix has been released in the meantime and people start exploiting the fact that appimagetool would insert an old, broken one as soon as the Internet connection is cut?

@TheAssassin
Copy link
Member

Can happen anytime again. In fact, will happen again - only a matter of time.

You can say that about any bug. See, today you introduced a few quick fixes. Hours later, they're unnecessary because the root cause has been fixed, causing additional work.

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

No branches or pull requests

2 participants