Is the namespace parameter necessary? about composer-bin-plugin HOT 14 CLOSED

On a another machine, I may need to sync my dotfiles, which includes a global composer.json (userland), with a set of dependencies ; currently, I will need to do a composer global bin foo require package 1 package 2, then a composer global bin bar require package 3, ... and so on.

I would like to be able to set the namespaces "definitely" in my composer file (see my suggestion) through a config of some sort so that I can actually just do a composer bin all install and that's it.

Even better I think, with this system, instead of having to make a bin install, just do an install which checks if there are namespaces (so that not all packages are namespaced... plugins for example), so that a simple composer install (composer installs plugins first and then activate them...) does the trick

from composer-bin-plugin.

The approach of this plugin is just to proxy commands to a namespace, to do what you suggest it'd need to do extra parsing, I also think it could be confusing as there'd be 2 different syntaxes.

I didn't get the other part, it should already be possible to have multiple packages in the same namespace, eg. composer bin org require org/project org/project2

from composer-bin-plugin.

But you can keep track of those namespaced composer.json still. For example:

~/.composer
    composer.json
    composer.lock
    vendor-bin/*/
        composer.json
        composer.lock

So if you keep them in sync with your dotfiles and have the hook, a simple composer global install will do all the work.

I would like to be able to set the namespaces "definitely" in my composer file (see my suggestion) through a config of some sort so that I can actually just do a composer bin all install and that's it.

If I understand correctly at the end of day you want to be able to declare another composer.json content from your main composer.json.

Whilst that could be done, I'm not sure that it's worth: it requires significant refactoring and you'll have to do something along the lines of

• go to the new created directory (we already do that)
• dump the content with your dep in a composer.json (right now we don't need to do that as the composer.json already exists)
• run composer
• remove the composer.json (otherwise you would introduce the issue of keeping that dumped composer.json with what you declare in the main composer.json)

It adds significant complexity for not much IMO

from composer-bin-plugin.

Instead of the namespace parameter, we could also add a "map" config in the composer.json ;

{
    "bin-bamarni": {
         "namespaces": {
            "foo": ["package 1", "package 2"],
            "bar": ["package 3"]
         }
    }
}

Of course, the namespace arg part could still be supported (and would overwrite the config if needed)

from composer-bin-plugin.

@Taluu : see #28

from composer-bin-plugin.

This is not quite the same actually. What I'm proposing here is not declaring dependencies and what not in the main composer json file. What I'm suggesting here is declaring the namespaces in the main composer file. For the root dependencies inside the root composer json file.

from composer-bin-plugin.

I see, what would this solve though, is there anything which is not supported currently that this would enable?

from composer-bin-plugin.

So that a simple composer bin install would then base itself on the config, without having to (potentially) forget the namespace, and install everything in one go.

The use-case that I have is actually to have a composer.json committed file on my dotFiles repo (I already have one) and just do a composer global bin install, without having to remember each namespaces and so on. Without having to do X commands for X namespaces.

from composer-bin-plugin.

@Taluu can't you already do that by adding a composer bin all install as a post-install hook?

from composer-bin-plugin.

On a new install, it won't be in the correct namespace (I guess it will be in a global one...)

from composer-bin-plugin.

What do you mean?

from composer-bin-plugin.

So if you keep them in sync with your dotfiles and have the hook

And that's the problem right there. I don't want to sync N composer.json files, I just want to sync one and be done with it.

And once it is installed (For the first time...), I don't really care for the sub created files. If the need ever arise that I need to change something (changing the version, removing the dep, ...), I can then deal with that separately. With such a config, and probably some inheritance, it's not really a problem anymore...

Removing a package from a namespace from the config will be pretty straightforward ; OK the binary would rot in the vendor-bin until next cleanup but who cares...

from composer-bin-plugin.

I don't want to sync N composer.json files, I just want to sync one and be done with it.

That's another story :) But as I said, IMO that use case don't really justify the added complexity (at least not enough for me to work on it) especially since it's a use case that arise only for global dependencies, which for me is very limited. Synchronising N composer.json looks way easier

IMO the true worth of that plugin is for project's composer.json where it allows to track tools like phpstan in your project without messing up with your project dependencies or more complex mono-repo configuration like done in https://github.com/nelmio/alice coupled with https://github.com/theofidry/composer-inheritance-plugin.

Kill global composer.json :P

from composer-bin-plugin.

And that's the problem right there. I don't want to sync N composer.json files, I just want to sync one and be done with it. — @Taluu on Sep 10, 2017, 3:26 PM GMT+4:30

I just migrated from cgr to bin plugin and I absolutely feel for you as I collect/sync my global packages in my dotfiles, too. But I agree with @theofidry that our usecase alone, doesn't justify the added complexity to the plugin.

I think we can live with an extra directory in our dotfiles.

from composer-bin-plugin.