Is it possible to install Castor locally with Composer ?

[mark-alexandre]

Hi,

I have properly read the "Get started" part in your documentation, and there is no mention on how to install it locally with composer. What I mean by locally is "per project", by adding jolicode/castor in the require part of a self made composer package which will contain the necessary custom commands for a project.

I expected to create such a package in order to easily add it to the composer.json of several website projects. But because this custom package will be installed in the vendor folder, even if I create a symlink from the bin to the project root, the file castor.php will not exist from the root and will not be able to find my commands definitions.

Am I doing something wrong ? I'm thinking about a way to add a castor.php file at the root of the project, and then import() the castor.php file of my custom Composer package (which has import() lines to in it).

Is this viable ? Do you have another solution maybe ?

Regards

[lyrixx]

Hello,

Thanks for reaching us.

You can install castor in your project with composer require jolicode/castor. Then you can create a castor.php file a the root of your project. Then you have to make sure castor is in your PATH. Or use the full path each time you use it

Details

```console $ symfony new dont-do-that --version=6.* * Creating a new Symfony 6.* project with Composer (running /home/gregoire/.local/bin/composer create-project symfony/skeleton /tmp/dont-do-that 6.* --no-interaction) * Setting up the project under Git version control (running git init /tmp/dont-do-that) [OK] Your project is now ready in /tmp/dont-do-that $ cd dont-do-that/ /tmp/dont-do-that $ composer require jolicode/castor ./composer.json has been updated Running composer update jolicode/castor Loading composer repositories with package information Restricting packages listed in "symfony/symfony" to "6.4.*" Updating dependencies Lock file operations: 12 installs, 0 updates, 0 removals - Locking jolicode/castor (v0.14.0) - Locking jolicode/jolinotif (v2.6.0) - Locking jolicode/php-os-helper (v0.1.0) - Locking monolog/monolog (3.5.0) - Locking nikic/php-parser (v4.19.1) - Locking spatie/ssh (1.10.0) - Locking symfony/expression-language (v6.4.3) - Locking symfony/http-client (v6.4.5) - Locking symfony/http-client-contracts (v3.4.0) - Locking symfony/monolog-bridge (v6.4.4) - Locking symfony/process (v6.4.4) - Locking symfony/translation-contracts (v3.4.1) Writing lock file Installing dependencies from lock file (including require-dev) Package operations: 12 installs, 0 updates, 0 removals - Downloading jolicode/castor (v0.14.0) - Installing symfony/translation-contracts (v3.4.1): Extracting archive - Installing symfony/process (v6.4.4): Extracting archive - Installing monolog/monolog (3.5.0): Extracting archive - Installing symfony/monolog-bridge (v6.4.4): Extracting archive - Installing symfony/http-client-contracts (v3.4.0): Extracting archive - Installing symfony/http-client (v6.4.5): Extracting archive - Installing symfony/expression-language (v6.4.3): Extracting archive - Installing spatie/ssh (1.10.0): Extracting archive - Installing nikic/php-parser (v4.19.1): Extracting archive - Installing jolicode/php-os-helper (v0.1.0): Extracting archive - Installing jolicode/jolinotif (v2.6.0): Extracting archive - Installing jolicode/castor (v0.14.0): Extracting archive Generating autoload files 36 packages you are using are looking for funding. Use the `composer fund` command to find out more! Run composer recipes at any time to see the status of your Symfony recipes. Executing script cache:clear [OK] Executing script assets:install public [OK] No security vulnerability advisories found. Using version ^0.14.0 for jolicode/castor $ vendor/bin/castor [WARNING] Could not find root "castor.php" file. Do you want to create a new project? (yes/no) [no]: > yes [OK] Project created. You can edit "castor.php" and write your own tasks. ! [NOTE] Run "castor" to see the available tasks. $ vendor/bin/castor castor v0.14.0 Usage: command [options] [arguments] Options: -h, --help Display help for the given command. When no command is given display help for the list command -q, --quiet Do not output any message -V, --version Display this application version --ansi|--no-ansi Force (or disable --no-ansi) ANSI output -n, --no-interaction Do not ask any interactive question -v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug Available commands: completion Dump the shell completion script hello Welcome to Castor! help Display help for a command list List commands $ vendor/bin/castor hello Hello gregoire! =============== ```

BUT I highly discourage you to do that

1. castor is a tool, and like every tools, it must be installed globally (like composer)
2. castor dependencies will conflict with your project requirements
3. you'll have to update castor in every single projet it's installed when a new version is released
4. it's a waste of bandwidth, storage

[lyrixx]

However, you may be interessed by repacking castor into a new phar.

It allows you to add many task and customization, then create a new standalone phar that does not require any deps. (a phar actually 😄)

[cedx]

@lyrixx You can perhaps take inspiration from PHPStan: when you install their package via Composer, it is the Phar archive which is installed locally. See https://packagist.org/packages/phpstan/phpstan (NO dependency!)

I also prefer to install tool like this one PER project instead of relying on a global installation. It's easier to update: composer outdated will tell me if a new version is available. Whereas with a manual installation of the Phar archive...

[ruudk]

I agree, to me this should be installed as part of the projects dependencies.

[lyrixx]

what are the benefits?

[cedx]

To be able to update Castor simply with composer update? To avoid problems when updating the global installation?

Let's imagine that in a new version of Castor, you introduce a breaking change. With a global installation, you have to migrate ALL your projects that depend on Castor. With a local installation, you can migrate each project one by one (or even not migrate certain projects: that's the whole point of using Composer, as each project can use the version it needs).

And I can't see myself manually installing the Phar archive in every one of my projects just to avoid a global installation.

[mark-alexandre]

To be able to update Castor simply with composer update? To avoid problems when updating the global installation?

Let's imagine that in a new version of Castor, you introduce a breaking change. With a global installation, you have to migrate ALL your projects that depend on Castor. With a local installation, you can migrate each project one by one (or even not migrate certain projects: that's the whole point of using Composer, as each project can use the version it needs).

And I can't see myself manually installing the Phar archive in every one of my projects just to avoid a global installation.

Yeah, that's basically my point of view, and the one of the company I'm working in too.

But personnally, I find the solution of doing a new repacked Phar pretty sexy. It will probably be the solution i'll opt for. By coupling the git remote repository with release delivered in PHAR and a VCS to download this PHAR with composer, the whole process of managing what I have named the "Project Manager" on a PER PROJECT approach will be easy for the team.

Thanks for all the suggestions.

[lyrixx]

To be able to update Castor simply with composer update?

each time a new castor release is available, you got a message, with the command to copy/paste

we may add a self-update command to simplify this usage.

To avoid problems when updating the global installation?

we are not aware of such problems. Please open an issue if you have any.

Let's imagine that in a new version of Castor, you introduce a breaking change.

No 😄 We are working hard to no reach this situation. And if it happen, we'll do our best to release a new version without the BC Break as soon as possible.

that's the whole point of using Composer, as each project can use the version it needs

Ok, so adding this support seems useless to me.

I understand your concerns, but again, we pay extra attention to not break the BC. ATM we are on the "0.x" releases, we are allowed to break the BC, but we don't. So you can be sure we'll be even more careful during the 1.x

Then, we provide nice upgrade path, the same as Symfony. basically, we add deprecation notices. Example:

• https://github.com/jolicode/castor/blob/main/src/functions.php#L139
• 

For the record, we use castor internally for almost 1 year for now, and we did not face the situation you describe.

So I invite you to try to install it globally, and tell us how it's going.

We don't want to provide solution to a problem that does not exist.

---

Anyway, you have posted your pro, allow me to put the const

• As said, it's a waste of brandwith : each developer has to download castor in each projet
• As said, it's a waste of storage
  • locally, you have N installation of castor (not a big deal... but still)
  • on github it's CRAZY 😨. You talk about phpstan. Did you even tried to clone the repo?

    phpstan/phpstan((1.10.65)) du -sh .git
    4,1G    .git

    Even if I love phpstan, this packaging system is a non-sense, it does not scale.

• castor is a build tools, so it must be installed globally. I guess you don't install Make per project. Same for inv, fab, etc (actually python package ecosystem is such a mess, that people tend to install one per project 😅, that why we created castor). It's also the same as docker, composer, yarn, cargo, etc
• you have an chicken/egg problem : you need castor to run castor install (that run composer install), so you have to run composer install manually to have castor (yes, you can run composer install manually, but it defeats the main usage of castor). It's really nice to clone a project, run castor start, and start hacking... I didn't open a readme for a while at jolicode since we have castor 🙃
• you have to deal with a long path to reach castor each time vendor/bin/castor instead of castor
• it does not play well with mono-repo + many application. In which project should I add castor ? okay, it could be in a tools directory. But then habits must be changed from one project vendor/bin/castor to another one tools/castor/vendor/bin/castor
• it does not work with application without composer (we have castor on some rust, or go application)

Yes, I'm sure we can work-around each situation, but it's clanky

---

That's being said, we already support (imho) too much way to install castor (the one with composer global is useless IMHO). I prefer to not add this one. I hope you understand

The solution provided by @mark-alexandre could fit your use-case 👍🏼

---

If my company was very strict about the castor policy, I think I would create a "virtual" composer package, with only one file in it. This file would download castor when you execute it based on the version in composer.json

[cedx]

Wow! Thanks for taking the time to give a such detailed answer. I totally understand your point of view :)

Maybe I'm too used to the way build tools work in the Node.js ecosystem (Gulp, Webpack, etc.), where these tools are divided in 2 packages (i.e. a "gulp-cli"/"webpack-cli" installed globally that calls a "gulp"/"webpack" installed locally in the version of your choice).

Anyway, thanks for creating Castor. It's so much better than the alternatives (Phing, Robo).