Package Manager Specification

[Kray-G]

Related to #232, let's think about Package Manager specification.

[Kray-G]

We need to think about two points of view.

• How to manage a package.
• How to write it in the code.

Package Management

Package will be directly stored in GitHub repository.

• For Repository
  • Add/Delete/List/Update
• For Package
  • Install/Uninstall/List/Update

In The Code

• Use a using directive, and @ at the head of the name.
• It is possible to specify the specific version.

using @packagename.dir.stem;
using @packagename(1.0.0).dir.stem;    // When you want to specify the specific version.

[Kray-G]

Thanks for your comment.

I have no idea so far. I think a package name must be unique.
Should I allow packages having a same name?

... Yeah, I understand it may be conflict even if I say no.
How about adding a user name?

using @packagename.dir.stem; // Conflict error would occur if the name were conflict, otherwise okay.
using @packagename:username.dir.stem;  // It will keep unique anytime.

[EDITTED] username was moved to the place after packagename because @ is needed as a keyword and it makes the parser keep simple.

[Kray-G]

If username is allowed and it's possible to share a package name, I guess username will be always needed anyway.
It is because a developer should always care about a possibility of conflicts.
After all, as everybody have to use a username always, I feel it will be redundant and not beautiful.

Don't you think the package name should be unique?
The package manager will detect a conflict of names.

I also think I want to share the same name, though.

[htsign]

Looks good.
What do you think about this packaging system? You will manage all packages by your central repository?
If you approve that users make local files or directories as their package, it seems this system can breaks easily.

[Kray-G]

I think it is based on the central repository.
Here is my assumption for that.

• The central repository has a list of a link to the package repository.
• The package repository has a zip file to be installed.
• A zip file is published and can be download by https from the released assets.
• A zip file contains package's files by the same structure as a structure after installation.

It is inspired by scoop.

And also I am still thinking about a user local file.
If a user prepares a zip file and the package manager can use it, I think it is the same as a remote repository style.
The local files are not used directly, but I guess a zip file of those can be installed same as installation from a remote.

[htsign]

I see. Surely, local files on same directory can't conflict their names.
Maybe you want the system to manage with metadata instead of filenames 😄