Future of haxelib

[ibilon]

Hi,

In the spirit of moving haxelib forward I think what it really needs is a good API,

it would make a very clean separation of logic and cli, and would allow tools to be easily compiled against it instead of running a haxelib process.

I propose this: https://gist.github.com/ibilon/74e5d8ed46cc25b95056 (only a draft ofc, need to see in practice if it works) there's only the current features of haxelib but before moving most code around we should consider what would be the roadmap of future features there's also a haxe-pseudocode example (draft too, didn't try to compile obviously) of how the api would be used to make the current commands.

thoughts?

[larsiusprime]

:+1:

[ncannasse]

FYI haxelib client has been built on a haxe remoting API since the very first version of it, you can have a look at the API here : https://github.com/HaxeFoundation/haxelib/blob/master/src/tools/haxelib/SiteApi.hx

[ibilon]

Thanks, I updated my suggestion with it, and move those into Server instead of HaxelibProvider, which makes more sense.

Also most data structure from here https://github.com/HaxeFoundation/haxelib/blob/master/src/tools/haxelib/Data.hx could stay the same, no need to change everything.

[ibilon]

https://github.com/openfl/hxpm/tree/haxelib/

It's a prototype of the API I linked in my first message, it has a cli completely decoupled from the logic code, it's multilingual and can easily be linked against/used by a third party tool.

It's not finished though, it's lacking the extraction of the downloaded zip, the code for upgrade and the submit, hg and git commands.

But it should be enough to give an idea about what kind of thing I'm talking about.

[nadako]

This looks like a great start! I'm thinking about finally refactoring haxelib (clean up the mess, separate haxelib functions from the ui, etc) and looks like you've already done a huge part. I'll look deeply in your code and comment further.

[ibilon]

Cool thanks.

There's a couple of things that didn't quite work the way I envisioned, the implicit save with setter actually make things confusing and more complex, the use of a provider to tell if it can use the uri was made to limit coupling but in the end there's still the need to list them all.

The use of exception did work like I expected and I think it's better than null values (exception now vs null pointer error later) but it does make verbose code.

Also something I didn't look at the time, but may be worth thing about, is to separate getting informations/displaying them from the validation/call to haxelib for the ui. To limit duplicated code between a cli and a gui mode (which I think would be a good addition).

[nadako]

the implicit save with setter actually make things confusing and more complex,

Yup, I agree, a setter that writes to filesystem is really bad practice IMO :)

the use of a provider to tell if it can use the uri was made to limit coupling but in the end there's still the need to list them all.

I think the provider system is still good, it allows us to add new types of haxelib sources easily. We should look into implementing something like this (related issue #238).

The use of exception did work like I expected and I think it's better than null values (exception now vs null pointer error later) but it does make verbose code.

That's for sure. No more Error: (+) pls! :)

---

Anyway, I decided to start in a separate branch with extracting a class that represents installed libraries and allows to install/uninstall/set current/set dev, but has no knowledge of anything else (so no network, ui or config files) and I think it's going good!