haxelib icon indicating copy to clipboard operation
haxelib copied to clipboard

Command plugin architecture for haxelib client

Open back2dos opened this issue 11 years ago • 15 comments

After thinking about #11 and how to keep the client small, I've had the following idea: Running haxelib <cmd> <args> could simply be a shortcut for haxelib run haxelib_cmd_<cmd> provided that <cmd> is unknown. This would allow us (and in fact everyone in the community) to add commands while keeping the client clean. The long prefix is simply meant to avoid taking up good names.

Thoughts on that?

back2dos avatar Mar 19 '13 13:03 back2dos

@back2dos: :+1: But as said here this maybe need approval from @ncannasse or @Simn

I really like this idea.

Maybe there should be some restriction who is allowed to publish haxelib plugins to haxelib and which haxelib plugin should be installed by default (respectively during the bootstrap)

TheHippo avatar Mar 19 '13 13:03 TheHippo

:+1:

Wouldn't the default plugins just be dependencies listed in haxelib.json?

As for haxelib run haxelib_cmd_<cmd>, don't official haxelib libraries need to have a unique name? So haxelib_cmd_<cmd> wouldn't be needed.

skial avatar Mar 19 '13 13:03 skial

As for haxelib run haxelib_cmd_, don't official haxelib libraries need to have a unique name? So haxelib_cmd_ wouldn't be needed.

Your premise is definitely right, but amusingly your conclusion the opposite of mine :D

I think that because all names are unique, haxelib commands should not block any concise project names. Suppose there's a command haxelib git implemented through a plugin.

  • I wouldn't call the project git, because I would expect such a project to represent git bindings for haxe (or be a haxe implementation of git)
  • I also wouldn't call the project haxelib_git, because such a project could potentially contain some basic infrastructure for git integration in haxelib.
  • So I would call it haxelib_cmd_git, which doesn't cause collisions and is very clear about what it does: it is the "haxelib command git".

Would you agree?

back2dos avatar Mar 19 '13 16:03 back2dos

Yep, that makes perfect sense.

I don't understand how I didn't get that from your original post :laughing:

skial avatar Mar 19 '13 16:03 skial

I think this would be well worth introducing.

I also have a question, which could affect Issue #58 and Issue #10: can one of these plugin commands override a built-in command?

For those two issues, that would allow:

  • haxelib_cmd_submit - will override the "submit" command to use https, so that the default haxelib isn't dependant on the https library. I know now that we're decoupled from the std library we can introduce more dependencies but I think it would be wise to be avoid this where possible.
  • haxelib_cmd_path - Massive or whoever could override the path command and do their custom lookups.
  • Custom 'haxelib install' could also checks your companies git repos etc

jasononeil avatar Jun 20 '13 02:06 jasononeil

Also, after implementing this, would we look at removing any functionality from the core?

Candidates include:

  • haxelib git (would have implications for "update" though...)
  • haxelib convertxml (almost definitely needs to go)

Any others?

jasononeil avatar Jun 20 '13 02:06 jasononeil

I would not remove haxelib git from the core.

ncannasse avatar Jun 20 '13 07:06 ncannasse

I guess having some sort of manifest file for plugins would be a good idea?

Allowing plugins to register for callbacks so, for example, haxelib svn, haxelib hg will be notified when haxelib upgrade is called.

On Thu, Jun 20, 2013 at 8:39 AM, Nicolas Cannasse [email protected]:

I would not remove haxelib git from the core.

— Reply to this email directly or view it on GitHubhttps://github.com/HaxeFoundation/haxelib/issues/20#issuecomment-19735369 .

skial avatar Jun 20 '13 08:06 skial

I have added svn and hg support https://github.com/Justinfront/haxelib/commit/0fde3486994faab7fe7623891a0e64195570ae9d

I suggest we add a "repository" command and attempt to detect the repository rather than adding the svn and hg commands, a plugin with a callback for svn and hg does not sound simple and I fear will be a long time in the making. But plugin for other functionality sounds good.

Justinfront avatar Oct 15 '13 04:10 Justinfront

Added more comment on my svn hg code here. https://github.com/HaxeFoundation/haxelib/issues/92#issuecomment-26309017

Justinfront avatar Oct 15 '13 04:10 Justinfront

Beside the fact that users can write custom commands,

would haxelib be separated into several modules, or would there be a haxelib core and some commands moved into optional plugins?(which ones? beside convertxml are their any optional?)

ibilon avatar Jun 21 '14 13:06 ibilon

I am all for having a really slim core and moving out as much as possible.

Reasons for that:

  1. The haxelib core should work without dependencies (otherwise you will have trouble building it since that would require haxelib, leading to a chicken and egg kind of problem). At the same time I think many people would love to actually use some of the great tools out there to add more features to haxelib.
  2. It should make it easier to approach the project and contribute and deploy those contributions.
  3. The selfupdate is still a little rickety and if the bulk of the commands is actually implemented through other haxelibs, then that's effectively not a problem anymore.

I would go far as having "submit" and "register" and what not be plugins. People have been asking for HTTPS when sending credentials. Which is something we cannot do, because you cannot have HTTPS on neko out of the box but we cannot add dependencies to haxelib either. It would also be nice to have some interactive submit process, much like jitsu or the like.

There could be a project called allfeatures that just adds all reviewed features as dependencies and then you can get the full feature set with haxelib install allfeatures.


Anyway, I think it's more important to actually have a rock solid implementation of this and then we can see how to use it best. We'll probably have to go back and forth between different approaches a bit anyway.

back2dos avatar Jun 23 '14 15:06 back2dos

I created tappi which is a neko plugin loader, its not perfect and I've probably made loads of mistakes as I haven't put any real thought into its design & probably not understanding bits of neko, but it works. It's there if its of any use to any one. Even if it shows you how not to do a neko plugin loader.

If you wanted to set it up, heres how

skial avatar Jun 23 '14 20:06 skial

Unfortunately that requires haxelib to run on neko, which it often doesn't (being run on the interpreter instead on neko and osx). As I said before, using haxelib run to invoke the plugins should probably do the job.

back2dos avatar Jun 24 '14 13:06 back2dos

I keep forgetting haxelib is now interpreted.

On Tue, Jun 24, 2014 at 2:04 PM, Juraj Kirchheim [email protected] wrote:

Unfortunately that requires haxelib to run on neko, which it often doesn't (being run on the interpreter instead on neko and osx). As I said before, using haxelib run to invoke the plugins should probably do the job.

— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/haxelib/issues/20#issuecomment-46967693 .

skial avatar Jun 24 '14 13:06 skial