Add an init command

[sagikazarmark]

It would be great if the manifest.json could be generated by this library. That said, I am having a weird feeling with the name manifest-publisher, since it would become a manager or something like that.

[cpliakas]

I love the idea about in init command. Are you willing to contribute?

Also happy to discuss project names. I admittedly suck at naming things. I just ask we do it in another thread to focus on the init functionality in this one.

[sagikazarmark]

I am absolutely willing to contribute.

I already have a plan:

1. Of course we need to generate a manifest.json file.
2. I am thinking about to check whether the php-phar-update package is actually installed (by composer). If the library uses composer AND it is not installed, It could offer the package for installation (If we say that this package is more than a publisher and update handler, the same could be for box.json, but I am not sure about that since the box.json is one of the assumptions)

[cpliakas]

So just to make sure we are on the same page, this library does automatically generate and publish a manifest.json file. My assumption is that you are proposing a command to just create the file and not publish, correct?

Also, any checks to ensure the required files are in tact I think would be a great thing.

[sagikazarmark]

I think generating (basically init), updating (to a new version), and publishing should be the different things.

The library itself is (usually) used as an executable (as I can see).

Init command: check if manifest.json generated. If not, start generation process, if yess, return with error. Check if php-phar-update is installed IN THE PROJECT (composer), offer it optionally to install, if not. (Same for box.json, but I am not sure of it. Opinion?) When called with an existing manifest.json: error? Generation could use git tags as a base. (IIRC there are some github-api implementations which might be able to get the releases and the files from it. But if we would like to be strict about the URL we support, then the init command could have to quiestions during initalization: url base defaulting to github releases site and the provided package name (from box.json?) which in turn let's the users to use a custom url for executable publishing)

Any other than init commands: Error if manifest.json does not exists.

Validate command: validate that the schema matches the required one, everything is in place, etc.

Update command: update the version in the manifest file. (optionally commit it (-c option) with an optional, custom commit message. So -c (commit with default commit message, -c my commit msg Additionally: commit should fail if the working directory is not empty?) Should fail if file cannot be updated.

Publish command: publish command is specific to gh-pages branch, so anyone who does not use gh-pages will not use your library. (This is why I suggested to change the name and the purpose of the library as well to a more general one) The above commands will not affect publish command. So basically it is a "wrapper" around update command: change branch, run update, push, change branch back. I am not sure where the version come from (git tags or box file), so that probably will need a bit of hacking, more clever solution then just running update command, but the logic is the same)

Actually I am not really sure how the updating part works. I found that all the phars are downloaded for some reason and the whole file is regenerated. If that is true, I would change it. The basic commands should work without actual internet connection/connection to the repo. For example I cannot always access the internal company repos (which will obviously not use gh-pages at all, but that does not mean it cannot have an update channel). I also found that the phars/data is always coming from github. There is a TargetInterface which in this case does not make any sense, since the source is always github, what could the target be? (Correct me if I am wrong in any statements above)

I hope I clearly explained how I imagine the thing. Generally I would just split up the publish command.

[sagikazarmark]

It ended up to be a bit long.

What we differ from what I explained and what is the actual library: it is currently stateless, always generates the whole manifest from start (as I can see). I wish to change that to a statefull strategy so the manifest only gets updated every time without any interact with github or any other third-parties by default (except the publish command, which this way could support any targets, hence the removal of the github-lockin. Targets could even publish the executable itself to basically anywhere, (again) hence the removal of the github lock-in).

[cpliakas]

Thanks for the details! I see the benefit of the init / validate commands more clearly.

Just to make sure my intentions are clear, I did attempt to create a system that would allow for pluggable targets. In order to get this in the hands of people like yourself more quickly for feedback and new ideas, I only added GitHub Pages. I think the system I created is pluggable, e.g. the target classes implement TargetInterface as you discovered. My company heavily uses AWS, so my thinking was for a target to be an S3 bucket where manifest.json files could be published to and access-controlled in S3.

One concern that I have is that I currently like there is one command to update / publish the manifest.json file. It words really well for me and although developers should have the ability to run each process independently, I don't want to force that. Thoughts?

One question I have is below:

I found that all the phars are downloaded for some reason and the whole file is regenerated. If that is true, I would change it.

How would you propose that we generate the sha1 for the phars if we cannot download them?

Thanks for all your ideas, this is great discussion.

[sagikazarmark]

We are talking about two things here:

1. Use Github as git repo of you project. In this case you probably publish your phars to github as well. However, I would like to remove the github lock-in completely.
2. Use Github as a git repo for your target. (Either phar or manifest target)

What I propose is that on initialization ask for the following parameters: Phar name: cliph Phar base URL: http://website.com/path/to/phars

Then the init command checks all the tags in your LOCAL git repo, for example: v1.0.0 v1.1.0 etc

and generates a file with

http://website.com/path/to/phars/cliph-v1.0.0.phar http://website.com/path/to/phars/cliph-v1.1.0.phar

IF there are actually existing tags then it makes sense to download them ONCE and generate sha hash for them. Otherwise everytime you tag a new release, only the newly added tag should be downloaded and updated with the file (or could be loaded from a local file???)

IF there are no existing tags when the init command is invoked then: a. either makes no sense to generate, return with error (meaning the file can only be generated AFTER a version has been tagged, I think it might not be the best idea) b. create an empy file and update it BEFORE a new tag is released

Actually I don't know how box solves this thing (updating phar version and the box.json as well, maybe that should be followed)

For the publish concern: The only thing I would force is init command. That should definitley be forced. As I said publish would be a wrapper around update, so basically it does not matter which you invoke. Since update only updates if there is a change, calling update/publish independently, multiple times, it does not matter.

Your concerns were righ, I was not clear. However, I have a question now: Do you see any relation with github in my explanation?

(meaning my concern is that this package currently supports repos which is actually stored at github, and the releases are available from github. I would like to remove that and make it optional. Maybe the terminus source could be introduced. However that is still a problem that these information should be stored somewhere (where to check the phars, where to put the manifest). So either some sort of build file should be introduced or should use box.json for this purpose. If we are moving towards merging into box, the latter could be a good idea.)