search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
90.74k stars 21.12k forks source link

Update Snapcraft.io version #35556

Open ksthiele opened 4 years ago

ksthiele commented 4 years ago

Godot version: 3.1

OS/device including version: Ubuntu/KDE Neon and every platform that supports Snaps

Issue description: When searching for "Godot" on https://snapcraft.io/store this version pops up: https://snapcraft.io/godot-3-1 which looks like a test version and is old.

But if you open https://snapcraft.io/godot directly the proper version pops up, which is also outdated, but not listed when you search for it

Calinou commented 4 years ago

The Snap version isn't officially supported here. I'd advise leaving a comment in this thread instead.

williamd1k0 commented 4 years ago

I don't use snap, but on linked pages it's marked as published by "Godot Engine (godot-developers) Verified account". So this can be confusing, as you said it's not officially supported.

akien-mga commented 4 years ago

I think @hpvb was handed over the maintainership by the Snapcraft team, but he hasn't really been available to update it further.

andrewebdev commented 4 years ago

The version I've been using is 3.1

snap info godot-3-1 
name:      godot-3-1
summary:   Godot 3.1
publisher: Godot Engine (godot-developers✓)
license:   unset
description: |
  blah
commands:
  - godot-3-1
snap-id:      YWFs9BQUFOGAzG3bubS7vB34RReoxOpE
tracking:     edge
refresh-date: 20 days ago, at 21:51 GMT
channels:
  stable:    –                         
  candidate: –                         
  beta:      –                         
  edge:      3.1.1 2019-06-13 (3) 22MB -
installed:   3.1.1            (3) 22MB -

I too would have loved the snap version was just a single "godot" and the snap would just update as with other snaps. Snaps have so many benefits and I would prefer being able to install via snap.

fcole90 commented 3 years ago

Alan Pope is currently maintaining the snap, and he unlisted it because of some bad bugs:

I marked it unlisted because I’m debugging an issue which causes it to crash on some systems. I wanted to just hold back the number of new installs while debugging.

Source: https://forum.snapcraft.io/t/godot-engine-call-for-testing/4997/15

fcole90 commented 3 years ago

I think issue this can be closed.

fcole90 commented 3 years ago

@ksthiele I think you can file issues for the snap here: https://github.com/popey/godotsnap, even if it looks abandoned... :thinking:

anrouxel commented 2 years ago

Hi, I am a student at the IUT of Nantes (France) and I created a New Snap of Godot Engine in my free time, because I thought it was a shame to have stopped putting Godot Engine on Snapcraft. And why not one day participate in open source projects. For example to participate in publishing Godot Engine on Snapcraft. Here is the repository of the Snap I created:

LinuxUserGD commented 1 year ago

Hi, I am a student at the IUT of Nantes (France) and I created a New Snap of Godot Engine in my free time, because I thought it was a shame to have stopped putting Godot Engine on Snapcraft. And why not one day participate in open source projects. For example to participate in publishing Godot Engine on Snapcraft. Here is the repository of the Snap I created:

* Godot Engine : https://github.com/anrouxel/godot-engine-snapcraft

* Godot Engine C# : https://github.com/anrouxel/godot-engine-mono-snapcraft
  Best Regards
  @patwork
  @hpvb

Seems to be fixed then unofficially https://snapcraft.io/gd-godot-engine-snapcraft

anrouxel commented 1 year ago

@LinuxUserGD Hi, I created the Snap for Godot Engine (https://snapcraft.io/gd-godot-engine-snapcraft). Best Regards

geekley commented 11 months ago

This situation with lots of duplicate unofficial snaps is really bad.

What's the impediment to the verified account of Godot Engine in snapcraft distributing official updated snaps? The one that was made officially is old and doesn't even show in search results (not even in this linked page), and (unless I'm mistaken) none of the available versions is updated as regularly as flatpak (yes, I know that one is technically unofficial too, but at least it's properly packaged and maintained by Flathub, without multiple duplicates).

Ideally there should be official snaps for (or equivalents with tracks/channels): godot3, godot3-mono godot4, godot4-dotnet

Can you please start supporting these officially with regular updates? And/or transfer ownership of whichever ones are currently working and properly sandboxed. This way there would be a default/official way of installing snap Godot reliably (e.g. installation paths in a default expected location facilitating tool interoperability, regular updates, same license, no confusion or mistrust, preferably no need for --classic escaping the sandbox, guarantee that it's compiled from the official sources without having to manually check that, etc).

patwork commented 11 months ago

Can you please start supporting these officially with regular updates?

It seems to me that the main problem stems from access to snapcraft, you first need to recover the login passwords for the godot-developers account and I do not know if anyone from the godot team is interested.

The whole operation requires an agreement between the snapcraft administrators, the person who currently has access to the godot-developers account and someone who will keep the godot snap updated.

@anrouxel are you interested in getting back on topic? If the passwords are currently in the hands of @tmm2k then from what I think he is still active in the godot scene.

As for the snap structure, I personally see it like this:

Godot 3 (snap 1)

Godot 3 MONO (snap 2)

Godot 4 (snap 3)

Godot 4 MONO (snap 4)

There is no point in combining versions 3 and 4 in one snap.

@anrouxel Wouldn't it be easier for you to just link the compiled official binaries in snap from the Godot website?

anrouxel commented 11 months ago

Hi @patwork, Your idea of doing what Blender does with Snapcraft is an interesting one. Because it would allow you to make a single Snapcraft package. Just choose the version you want. It would be good to keep the latest/stable branches so that you always have the latest version on that branch. And why not group the mono and normal versions in a single package. What I mean is that when you download Godot from Snapcraft, you get the mono version straight away. Because the mono version includes the normal version. To create new branches and have the classic mode on Snapcraft. You need to be validated as the Godot account. What would be nice is for the Snapcraft file to be included in the Godot project repository for greater flexibility. Because I rely on git to get the latest tags from the repository.

Blender Snapcraft version : latest/stable 4.0.1 17 November 2023
latest/edge 4.1.0 Today
4.0/stable 4.0.1 17 November 2023
3.6lts/stable 3.6.5 20 October 2023
3.5/stable 3.5.1 25 April 2023
3.4/stable 3.4.1 20 December 2022
3.3lts/stable 3.3.12 20 October 2023
3.2/stable 3.2.2 3 August 2022
3.1/stable 3.1.2 1 April 2022
3.0/stable 3.0.1 26 January 2022
2.93lts/stable 2.93.18 23 May 2023
2.92/stable 2.92.0 25 February 2021
2.91/stable 2.91.2 20 January 2021
2.90/stable 2.90.1 24 November 2020
2.83lts/stable 2.83.20 20 April 2022
2.82/stable 2.82a 25 June 2020
2.81/stable 2.81a 25 June 2020
2.8/stable 2.83.10 9 December 2020

Best regards.

anrouxel

andrewebdev commented 11 months ago

You should really talk to the snapcraft team. They've assisted many other projects with adding their projects on snap. They even did many of the most used packages themselves.

Calinou commented 11 months ago

Note that we already have trouble making the Flatpak fully functional, which led to it being marked as unofficial. I expect the Snap will encounter similar issues unless it goes through classic confinment, which I would strongly recommend for maintenance reasons.

We need Godot within Flatpak/Snap to be fully-featured with no limitations whatsoever before we can consider making either of these options official. This includes parts that are difficult to resolve such as https://github.com/flathub/org.godotengine.GodotSharp/issues/2.

To my knowledge, no regular contributors are available to maintain the Snap, while the Flatpak is mainly worked on by me and Zishan-Rahman. Regular is important, as we need to ensure the contributor(s) remain available to handle Godot updates and issues that inevitably pop up over time.

fcole90 commented 11 months ago

I expect the Snap will encounter similar issues unless it goes through classic confinment, which I would strongly recommend for maintenance reasons.

I think using classic confinement is the best way forward when packaging software as complex as Godot, that needs libs, different resources and so on. I think to remember it's the same way VS Code is packaged (and probably other IDE and development platforms), for instance 😊

geekley commented 11 months ago

using classic confinement

Well, personally I always want to avoid installing any unsandboxed software - I usually only make exceptions when it's both open-source and reproducible builds. With those guarantees, I wouldn't mind it.

So it's better if Godot can be confined, but if not, then I guess --classic is valid, because there is already a confined version through Flatpak for whoever prefers that (I feel like Flatpak is stricter than Snap with its way of doing sandboxing anyway). The only snap I use is indeed an unconfined IDE (but it's the open-source VSCodium instead of VSCode) precisely to avoid issues with sandboxing (e.g. when using the integrated terminal; running arbitrary tasks and extensions).

Still, I don't feel like Godot should be unconfined like a general-purpose IDE if it's possible to avoid that. After all, sandboxing is one important feature of snaps - without that, the only benefit would be the auto-update system. The linked Flathub issue is exclusive to the way Flatpak does sandboxing (you need special commands like flatpak-spawn or /run/host/... to run things outside the sandbox, unlike snap I think); and it's not difficult to resolve (I already proposed a solution).

There's also the case where if you know Godot can work inside a snap sandbox, then you can guarantee the same goes for games one may want to build and distribute in the snap store in a sandbox.