Update Installation Instructions

[SerheyDolgushev]

Installation via Composer was added recently, which is a great idea - the more ways phanalist can be installed the better it is. But I don't think it should be the default way to go, and I am opening this issue to discuss it.

Right now we have a ./release.sh script that generates standalone binaries for multiple platforms. And the simplest way to run phanalist is just to download the corresponding compiled executable. It will allow checking multiple projects locally without modifying their sources.

In my opinion phanalist is similar to Symfony CLI: both of them are tools designed to be used for PHP projects, which are written in non-PHP. And I guess we should follow the way how Symfony CLI is installed: just by downloading the compiled binary.

In addition to that composer and docker options seem to work only for x86_64-unknown-linux-gnu, but not for other platforms.

That is why I suggest to:

1. Make complied binaries the default installation option.
2. Create a tool that will download binary that corresponds to the platform of the current user. Basically, this tool will choose the correct platform for the current user.
3. For composer implement support for all the platforms, for which we compile binaries. At the moment it supports only x86_64-unknown-linux-gnu.
4. Make docker the least preferable option to install, and make sure it works for multiple platforms. At the moment it supports only linux/amd64.

[SerheyDolgushev]

@denzyldick what do you think about the points above?

[denzyldick]

Hi Sergii,

Composer is not the default way to install. I think it's an easier way.

My idea is to support all common installation methods in a CI/CD pipeline. I know PHP setups that use Composer for the other static analysis tools.

There are times when I just want to execute a docker run, composer, etc. I also think we should also add Phanalist to homebrew for apple.

I'm up for your suggestion about a tool that can automatically detect the architecture and download the correct binary. The tool you are suggesting should be just another way to install. But this tool should also be able to log Analytics data, etc. If we directly make the binaries downloadable, we have no way of knowing if the project is growing in the number of downloads.

Right now it's possible to view the number of downloads in multiple places. The GitHub repository, the image repo and packagist.org.

There is also currently a release.workflow that i was testing out for creating different binaries when releasing. I would like to automatically do everything. Right now I'm on my mobile. I'm only able to edit code.

I like the idea of having a CI/CD that can set everything up correctly when releasing a new release. You previously said that there are some issues with the licensing on apple. Is this something that you think that we aren't able to solve?

I also saw that the Symfony CLI is written in GoLang and that they have signature verification. This is also something we should implement. I think there are companies/people that want to make sure that the compiled binary matches the source code.

Right now, Composer only supports 1 architecture. This is something that I will be solving next week. This is also the same for the Docker.

We are on the same page. I want every visitor (on all common Platform) should be able to test the performance of Phanalist in their current CI/CD, without doing too much.

[SerheyDolgushev]

In #42 the new init.sh script was introduced, which detects current user platform and downloads appropriate exectuable. Lets use this installation method as the default for now (as it is the simpliest one), but lets maintain the others. Does GitHub provide analytics for https://raw.githubusercontent.com/denzyldick/phanalist/main/bin/init.sh?

Regarding the releases, Symfony CLI is using https://goreleaser.com/. I was trying to find something similar for rust, but had no luck with it. Also, seems like there is no easy way to build macOS target from Linux: https://users.rust-lang.org/t/is-cross-compile-from-linux-to-mac-supported/95105/2. So seems like for now we need running manually bin/release.sh before each release. We could automate it in the future (at least for non-macOS targets).

So far the remaining items are:

1. Fix multiple platforms for Composer.
2. Fix multiple platforms for Docker.
3. Investigate options to automate builds as part of the release process (can be done after v1.0).

@denzyldick are there any other items that are not covered by this list?

[denzyldick]

I tested it, it works fine. It was really fast.

I don't think there is analytics on that endpoint. Can you see the insight page?

I find working with the binary fast. We can make it the default, I will test this in WSL 2 on Windows.

• Test if everything works fine on WSL.
• Fix multiple platforms for Composer.
• Fix multiple platforms for Docker.
• Investigate options to automate builds as part of the release process (can be done after v1.0). 👍🏿

I think we can put this issue in the backlog. You are right, we can do them after the release, and if someone needs it they can make a PR or use the binaries.