Command plugin architecture for haxelib client about haxelib HOT 15 OPEN

@back2dos: 👍 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)

from haxelib.

👍

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.

from haxelib.

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?

from haxelib.

Yep, that makes perfect sense.

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

from haxelib.

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

from haxelib.

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?

from haxelib.

I would not remove haxelib git from the core.

from haxelib.

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//issues/20#issuecomment-19735369
.

from haxelib.

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.

from haxelib.

Added more comment on my svn hg code here.
#92 (comment)

from haxelib.

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?)

from haxelib.

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.

from haxelib.

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

from haxelib.

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.

from haxelib.

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
#20 (comment)
.

from haxelib.