-
Notifications
You must be signed in to change notification settings - Fork 100
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
Add a package manager #62
Comments
(in case it wasn't clear, with input from the community and further study of how the distribution works, I may be willing to write the package manager) |
You could just host a Snakeware-specific PyPI server; then you can simply use |
I think using the existing PyPI is the right approach here, and very inline with the Snakeware philosophy |
It would be cool to only ship stock Python (and pip) with snakeware releases, and then use pip to install required packages over the internet on first boot. We'll have to get networking and "persistence" fleshed out first though |
On Thu Jun 4, 2020 at 1:41 PM +03, Josh Moore wrote:
It would be cool to only ship stock Python (and pip) with snakeware
releases, and then use pip to install required packages over the
internet on first boot.
That might not be a good idea. I would recommend snakeware's root to be
fully read only, and have the ability to easily be switched out.
That way, if Pygame, for example, broke after an update, you can always
download an older version and load it into a live USB or whatever, and
keep the OS working.
Also, since I managed to get snakeware down to a ~50MB live USB while
doing some experiments, space shouldn't be an issue at all.
That said, users should definitely be able to download modules
themselves, so a read-write user partition will be needed.
We'll have to get networking and "persistence" fleshed out first though
A basic curses-like wifi/ethernet connection manager would be more than
enough I assume. For the actual hard work, we can delegate to dhcpcd (or
Busybox's equivalent) and wpa_supplicant.
|
As the distribution grows, it may stop making sense to package all apps into it. What kinds of package management solutions make sense for this project?
My preliminary thoughts are:
Packages are maintained in their own repo by their respective maintainers. There is one central repository that hosts package metadata (maybe JSON?) of 'approved' packages. The package manager syncs to the master list (with the option of using other package lists?) and uses the metadata to resolve dependencies, clone and install applications, etc.
The text was updated successfully, but these errors were encountered: