Next Release: Reduce the distribution to just one method for the next release

[gennadigennadigennadi]

However, I would like to open a general discussion about distribution as a whole. Now we are supporting way too many ways of distributing the package. PHAR, shim, source, now multiple executables. It is not tenable. They are not even equivalent in terms of features.

I had a zoom call with the author of PHPStan last week and we discussed this briefly. He told me PHPStan used to be in the same situation as we are right now. The solution he came up with was to reduce the distribution to just one method. I think we should do the same.

Originally posted by @patrickkusebauch in #1238 (review)

[gennadigennadigennadi]

Right now I'm experimenting with the phpstan/rector approaches and as soon as I'm done with it, there will be a new release.

[gennadigennadigennadi]

From the conversation: #1002

I don't now if this is doable (right now), becaue it would be necessary to sunset deptrac-shim at the same time. Would you also abandoned the .phar?

@patrickkusebauch

I don't have a vested interest in which distribution method we choose. I just want to have only one, so that we don't have the burden of all the build processes and incompatibilities between them (like writing extensions does not work everywhere). I personally use the direct require-dev composer dependency of deptrac, but I do not object picking something else. Completely self-contained distribution with all the dependencies that will not cause any collisions with other installed tools and allows us to pin our own internal dependencies to the version that we need to is probably the best choice.

I'll move the conversion to this issue, because the next release is not only about the ConfigBuilder ;-).

I look into the way phpstan and rector are solving this problem. And for now I'm planing to add a new repo qossmic/deptrac-src for the development and qossmic/deptrac will become our main distrubtion channel. Which will have, similar to rector, scoped dependencies. In addition to that I think I will also bundle a .phar next to the bin/deptrac. This way phive should still work like before.
And I will also update the .gitattributes to slim down the github release.

At the same time I will archive qossmic/deptrac-shim and everyone who is ready for the new releae can just migrate to qossmic/qossmic.

Because there are multiple moving pieces I will do some beta-release.

[gennadigennadigennadi]

At the moment I'm experimenting here https://github.com/gennadigennadigennadi/deptrac/tree/update-build-system and here https://github.com/qossmic/deptrac/tree/poc/scoped-deptrac.

The most interesting part is the build script build-deptrac.sh.

[ilnytskyi]

I my project I have conflicting deps with xdebug-handler package. So shim version allows me to still use deptrac

[gennadigennadigennadi]

@ilnytskyi No worries, the idea is to deliver all Deptrac dependencies in their own scope as part of Deptrac.
This way it won’t conflict with your dependencies.

[patrickkusebauch]

Found a blog article from Tomas Votruba that might be useful in tacking this issue: https://tomasvotruba.com/blog/how-to-scope-your-php-tool-in-10-steps

[gennadigennadigennadi]

Thank you for the link. Right now I just have setup everything as a script, automate every thing as a GitHub action would be awesome and reduce the release fatigue.

[gennadigennadigennadi]

https://github.com/qossmic/deptrac/releases/tag/2.0.0-alpha is now available.

[patrickkusebauch]

@gennadigennadigennadi should we close this issue?

[gennadigennadigennadi]

There is still no final release, just the alpha.and I would like to update the changelog and and sunset the shim for real.

But I think we could close this issue and I would track the process elsewhere.

[gennadigennadigennadi]

I will keep this one open, because I had to open a bug report for php.scoper (humbug/php-scoper#958). Possible it's our config for scoper, but I don't see the problem.

#1403 is not correctly scoped. :-(