CC: Tweaked

CC: Tweaked

57M Downloads

Add Package Manager

JakobDev opened this issue ยท 9 comments

commented

I think it's time for adding a package manager to CCT, which makes it easier for users to install programs and modules.

I think, the best idea to implement this is something like Packman: Every user has his own repo which he maintain himself. We have only one centralized file which is the list of the repos.

Here is examole for a repo file:

{
    "example": {
        "name": "Example Program",
        "description": "This is a example program",
        "files": [
            [
                "test.txt",
                "https://example.com"
            ]
        ],
        "dependencies": []
    }
}

It is formated as json, so it can be safe loaded wth the new function wothout the risk of code execution. Of course, we can add more metadate fields.

The above example in my repo could be installed with manager install jakobdev/example.

commented

I think it's clear that this issue is probably going to remain open for ever - we're all very good at bikeshedding. I think for the time being, it's probably best to let the community continue to explore different designs. I know several people are doing interesting things on Discord at least.

commented

Personally, I think adding a whole package manager to CraftOS kind of makes it feel a bit more complex. I believe CraftOS should be a somewhat basic system that is easily expanded by the user, and doesn't really have many set rules. Also, adding a default package manager will kill demand for any other package manager, thus reducing people's desire to create one, which I feel is one of those types of projects that a user should try to attempt at least once, even if it's only as a personal challenge. I am a bit biased myself, though, as I have started at least three projects to create a package manager. I think the process of installing programs should be left up to the creator to decide how to implement, instead of having them go through certain pre-defined steps to package, upload, and distribute their program. Having the user run pastebin run abcd1234 is simple enough, and a creator can set up their installation process however they want.

commented

But why?

commented

What's the problem with pastebin run 1NsT4LleR?

commented

Why not just ship Lyqyds packman, the license is compatible and there is already a big catalog of programs

Also agreeing with @Jummit's reply though.

commented

I think there's definite value in having a package manager. pastebin run x is fine for computers with a single task (and thus only need a single program). When you start trying to install multiple things, it gets an utter mess.

That said, I think most of my comments from #203 (comment) (and later comments) still stand and do need to be discussed. I for one have not found a design I like which doesn't end up being overly complicated.

commented

Looking at that comment @SquidDev I wonder if having the FS API being able to make hard links/symbolic links could solve the conflicting file issue, perhaps with version subfolders to prevent the inevitable conflict of two programs requiring different versions of the same library.

The symbolic links could even only exist in Lua, so that we don't need to add Java code.

In fact, I might try adding symbolic link like stuff to FS and making a pull request.

commented

wonder if having the FS API being able to make hard links/symbolic links

Runs.

In all seriousness, I don't really think they're a necessity. It feels much more elegant to do wrangle that on the package loader level rather than the filesystem one.

commented

I don't think the package manager should support versioning. That's to complex in my opinion. It's better to only download files to a specific place like my example above.

The problem, why I don't want to use packman, is that packman only supports one file per package. If you need multiple files e.g. for packing redirection, which has for each level one file, you need to create a extra package for each level.