Create UpdateTool update file.md

[ghost]

UpdateTool!

[oeed]

Need a bit more information really, can you explain what this is and give an example of the format?

[ghost]

hmk, will download an old version of swiftos and do updatetool -d!

[ghost]

Ok. added an example, and fixed a little error.

[oeed]

Hmmm, I can see why something like this would be useful to standardise.

It might be worth to have a bit of discussion on the forum topic about whether or not something that is for one specific program should be standardised.

I think it still needs more clarification, but as we have only just proposed this GitHub system I'd wait until we sort out the details.

[ghost]

Ok.

[oeed]

How are these files generated? It looks like it essentially lists the files to download and delete, so are you making these manually? Could this be done without the file by storing the current tag and comparing it to the current tag on GitHub?

[SquidDev]

If we are going to have an standard for package formats I'd like to see something closer to Grin-Get or Packman's functionality. These are the features I'd consider "essential":

• Installation from multiple sources/formats (Pastebin, GitHub, Grin?, Generic URL?)
• Dependency management
• Uninstallation/cleanup capability: Sometimes files add to the startup, which a simple delete will not be able to handle.

I'd suggest something like:

{
    name = "Foobar",
    version = "v23.5", -- Can have VCS tag or commit hash
    source = {"github", "SquidDev/FooBar"} -- Or pastebin, url, etc... Not sure about this format.
    install = "bin/setup.lua" -- Script to run on setup/update
    uninstall = "bin/remove.lua" -- Script to run on remove
    dependencies = {
         {"github", "SquidDev/Dependency", ">=v2.4"} -- Again, not sure about the syntax.
    }
}

That may just be me overcomplicating things though :stuck_out_tongue:.

[oeed]

So a bit like NPM packages? They certainly would be useful. Excuse my ignorance, but is that format from Packman or Grin, or are they just possible sources?

[SquidDev]

It is just something I wrote off the top of my head. Grin uses this format. Packman uses a more centralized format: all projects should be in one file, which I don't think is as great.

I'm also thinking that it might be a good idea to create a "file structure" for larger projects: programs should live under "bin", public APIs under "lib", though people are less likely to accept that.

[oeed]

Ah I see. I'd vote textutils.serialise rather JSON or the format Packman uses. That format looks good to me. What we don't want to do is this though. ![http://imgs.xkcd.com/comics/making_things_difficult.png]

It's also quite different to what FlareHAX0R is suggesting.

[ghost]

@SquidDev you should propose that in a different PR, just sayin

[ghost]

Also @SquidDev this is not a package manager, it's an updater.

[viluon]

Before publishing a standard proposal, ask yourself these questions:

• [x] Does your proposal/format really need to be standardized? Standards exist to increase cross-platform compatibility and keep reinventing the wheel to a minimum. In many cases, however, the proposal can be overly specific or so simple that standardizing it yields little to no benefits.
• [ ] If your standard gets accepted, will its users benefit from it? Does your proposal help solve frequent issues related to the category it should be used in? Does it help with compatibility (esp. backward and forward compatibility with future standard revisions)? Is it easy to use?
• [ ] Is your proposed standard easy to use? Does it require third-party code or brand new code to be written in order to be used properly, or do you pack needed utilities with the proposal? Are these utilities efficient?

You might want to add these into the README @oeed ;)

[ghost]

I am planning on making a standalone API using this format!

[viluon]

What for @FlareHAX0R? I see no benefits in standardizing this. Besides, you should have done that before opening a Pull Request. Read the README first, please.

[oeed]

Yeah for now I'll close this. If you make an API and work on your proposal more (you haven't explained how these files are made and why it's necessary when there are already GitHub updaters out there).

If and when you improve the RFC comment and we might open it up again.