Roadmap to v2.0.0

[clue]

It's my understanding that this project seems to work reasonably well for its intended use case - and at the same time fails to implement many of the nice-to-have features that were added over time.

As such, I'm planning to work towards a breaking v2.0.0 release to bring this project back to its basics: Building phar files for any project with as little configuration as possible.

In particular, this means that it will focus on building only and will not have any of the additional search and install commands anymore. This way, we can remove a significant piece of the current code base, no longer require any command line invocations (no composer, no git, no nothing) and focus on building the best tool to build a phar from a project directory.

On top of this, we may provide some documentation on how to build arbitrary projects by Composer package name or git repository, most of which can be achieved with a single line bash script.

I'm opening this ticket for the reference and to hopefully spark some discussion. I'm still working towards creating a feature/maintenance release for the v1 series, but future development will focus just on building phars.

[ppetermann]

Mh, that's a bit of a bummer, being able to install tools easily was my main use case for phar-composer and what I've been recommending it for over the years.

However that opens to me the question: if basically you are reducing the features to the same things Box wants to do, wouldn't it make sense to bundle efforts with them?

[ppetermann]

Nevermind, box seems to be stale

[clue]

@ppetermann Good point, this is definitely something to consider for the upcoming version! It looks like @theofidry has done an outstanding job of updating Box and improving it significantly since the last time I checked: https://github.com/humbug/box

Box used to rely heavily on explicit configuration, which was part of the motivation for creating phar-composer. Nowadays, they seem to be much more similar.

Perhaps it will make more sense to join efforts and deprecate one of the projects in the future, I'm open for any input and don't feel maintaining two very similar projects is a good time investment in the long run 👍 Ideally, another project may focus on the "higher level" decisions like bundling arbitrary projects by name instead of just project directories, installing and managing them system-wide etc. Let me know what you think 👍

[theofidry]

Thanks for the mention :)

I would be more than happy to receive help for Box. I did some efforts to allow to make it work as easily as possible with most projects, although there might be some points to improve still.

That said I admit I think the next big points of improvements are rather around the PHAR tooling than the PHAR bundling itself:

• PHP-Scoper cf. PHAR code isolation
• Better usability with the box diff command (which heavily relies on pharaoh
• Possibility to go a step further and try to ship a true binary instead of a PHP app, see Compile your app into a single binary box-project/box#331
• Provide an easier way to distribute PHARs compatible with an old codebase without forcing the codebase to stay on old PHP versions: Transpile you app from PHP7 to PHP5 box-project/box#330
• Make it easier to sign a PHAR: Add GPG utility box-project/box#329 Secure your PHAR box-project/box#15
• Make it easier to install a PHAR: Add installer box-project/box#8
• Speed up the PHAR bundling when using PHP-Scoper: WIP: leverage krakjoe/parallel box-project/box#429
• Consolidating the codebase like helping out with the new version of https://github.com/doctrine/annotations

So although the idea of bundling a PHAR might seem to be a fun thing to do, there is still a lot to do afterwards! 😄

[Steveorevo]

Great work. I would like to see public/private key signing as a command line option. I know this feature is mentioned as being apart of the official phar format but not sure how it works. The ability to sign and verify if a phar is as intended, and not altered is undeniably of increasing importance. Perhaps phar-composer could include a utility to validate a signed archive too?