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

Stop publishing Linux binaries #3210

Open
aivarannamaa opened this issue May 30, 2024 · 3 comments
Open

Stop publishing Linux binaries #3210

aivarannamaa opened this issue May 30, 2024 · 3 comments

Comments

@aivarannamaa
Copy link
Member

As Linux distributions have become more diverse (more architectures, more differences in core libraries), it is more difficult to produce binaries. I'll rather focus on improving the installation script, which installs necessary system packages, creates a special venv and installs Thonny there.

@aivarannamaa
Copy link
Member Author

TODO: test, also pay attention to produced uninstaller

@sameersharma2006
Copy link

sameersharma2006 commented Jun 1, 2024

Snap Maintainer here,

Although this is done and i understand the reason behind this , i oppose this as apt/deb packaging doesn't have latest thonny versions, snaps with the help of the above binaries was serving as a supplement to provide latest version to Ubuntu & other distros supported by snapd(Debian included).
Hence IMHO the effort/time needed to build the binaries were legitimate & justified.

Even after months of attempts , i have failed to make snap independent of upstream binaries.
I guess Thonny-5.x as a snap won't be available until i sort out this(Seems impossible) & hence i believe once thonny 5.x is published & i am unable to get it snapped, i will retire the snap builds & post a depreciation notice in the forum. 🤷

@brianlinuxing
Copy link

I can appreciate the issue here @aivarannamaa , as a long term Linux user of Thonny, I would say as long as the thonny-x.x.x-86_64.tar.gz is shipped then that’s workable for me. :)

Equally, other solutions** might be to bring on more people, delegate the building of machine specific releases (a common practice on many other projects) or seek automated CI/CD solutions for producing builds where appropriate (large vendors will often offer free credits for open source projectS to do such things, so potentially almost zero cost).

[** You might be doing part or all of these already, it is unclear to me.)

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

No branches or pull requests

3 participants