hoaproject / Core

If the 'hoa' binary strictly depends on Hoa\Console to be installed, I feel it would be better if the binary came with Hoa\Console.

Without Hoa\Console you basically end up with a broken binary in everybody's bin directory. Since Hoa\Console depends on Hoa\Core to work anyway, it would be more logical (in my head at least) that it ships with Hoa\Console.

That's a question I have since a long time. I am not comfortable with the idea of delivering a broken binary. The compromise I found is to log messages:

Core/composer.json

Lines 32 to 34 in 1e62154

    
           "hoa/console"   : "To use the `hoa` script.", 
        
           "hoa/dispatcher": "To use the `hoa` script.", 
        
           "hoa/router"    : "To use the `hoa` script.",

with suggest in composer.json. I wonder if this is possible to come with a Composer's plugin that install the hoa binary if all requirements are satisfied (i.e. if hoa/router, hoa/dispatcher and hoa/console are installed)?

I don't think that's a good idea to install the hoa binary with hoa/console because:

hoa/console does not require neither hoa/dispatcher or hoa/router (https://github.com/hoaproject/Console/blob/e4450ac42d0e807bca7a39bba5b6fede65f54bdd/composer.json),
hoa/console is a library, used in combination with hoa/router and hoa/dispatcher to create the hoa binary,
All libraries come with a Bin/ directory, containing several commands used by the hoa binary; consequently all libraries would depend on hoa/console, and this is not good.

So it's not strictly related.

What do you think about having a Composer's plugin? /cc @hoaproject/hoackers

/ping @jubianchi (as you asked on IRC)

I think the 'official' answer would be to create a separate package that distributes the binary and depends on all three packages.

But, if it were me, I wouldn't be fully sure if I would want to do that... it does reduce the visibility of the binary.

@evert Welcome in my dilema :-].

Have you put any further thought towards this yet?

Not yet. I will try to open a discussion about the split of Hoa\Core very soon. My plans seem correct. This will involve this issue.

@Hywan Here are my thoughts (based on what I personnally think and on the feedbacks I got from several users of other libraries I contribute to) about this issue :

The fact that libraries provide some commands accessible through the hoa binary makes them kind of dependent to hoa/console. hoa/core in particular is where the dependency exists. This is some kind of optional dependency because the library just works without hoa/console only users using the CLI will notice the dependency. But,
I once contributed to a library (which I won't link here because the use case is not really related) and we came though a "optional dependency" problem. I used composer suggests and I got the following answer: There's no such thing as an optional dependency. I do not totally agree with those statements but OK, let's consider them.
I totally understand you don't want to make a hard-dependency between hoa/core and hoa/console because, most of the time, the hoa binary will not be used and the user will get useless dependencies.
I totally understand you don't want to hide the hoa binary in a seperate package, but...

Extracting the hoa binary to its own package seems to be the best solution:

no more unusable (when dependencies are not here) binary in hoa/core
no more "optional dependencies" in hoa/core
more user-friendly: user will not have to bother with the binary dependencies and eventual errors, everything will be handled by composer (or any other loader)
will require an extra package to be installed
will probably require some work to correctly extract the biary's logic (finding commands among other hoa libraries)
only a single suggest in each hoa library providing CLI commands

I can easily imagine a new package called hoa/cli with every dependencies hard-linked with composer.json. This package would be responsible of installing the hoa binary, its dependencies and publishing the binary in the root-package bin folder if asked.

My 2 cents ;)

So, what about putting hoa CLI tools into Hoa\Devtools?

the hoa commands are not all only related to dev ?

Agree. So, maybe we have to go through hoa/cli? I don't like the name though. Any better idea? It's like an empty “package”. Do we keep the same naming for these packages?

Please @hoaproject/hoackers, vote!

hoa/cli is a common name and everybody know what this package do only with the name.

"It's a cli for hoa"

So, 👍 @jubianchi

Ok. Any volunteer? /cc @hoaproject/hoackers

@Hywan I'm on it ;)

@jubianchi Perfect :-). Are you a commiter to create the new repository? Please, come on IRC to discuss about that.

I'm coming on IRC right now ;)

Feedbacks welcome: https://github.com/jubianchi/hoaproject-cli/

Done. Hoa\Cli.

👍

awesome!

	"hoa/console" : "To use the `hoa` script.",
	"hoa/dispatcher": "To use the `hoa` script.",
	"hoa/router" : "To use the `hoa` script.",

The 'hoa' binary should not be installed with Core