Be clearer about how usable the current state of the project is

[copumpkin]

This is more of a documentation issue than a functionality one. I was skimming the readme and whatever readings I could find, and was unable to figure out an answer to "if I were to start using this today, would I be signing up for a world of pain?"

It seems like a question worth answering prominently. I don't see much activity on the issue tracker or the mailing list, so it's hard to tell.

[freekh]

Good point! Will update! Until I do: the current state is that you should wait around 2 or so weeks. We are rolling out an alpha which you can try. The amount of pain to use it should be minimum, but it is an alpha.

It’s cool to hear that you are interested though! Are you on Scala or…?

F

On 05 May 2014, at 18:50, Daniel Peebles notifications@github.com wrote:

This is more of a documentation issue than a functionality one. I was skimming the readme and whatever readings I could find, and was unable to figure out an answer to "if I were to start using this today, would I be signing up for a world of pain?"

It seems like a question worth answering prominently. I don't see much activity on the issue tracker or the mailing list, so it's hard to tell.

— Reply to this email directly or view it on GitHub.

[copumpkin]

Yup, I'm on Scala using sbt and have been wishing for a dependency management system like this for a while, so I'm excited :)

[freekh]

That is awesome to hear! Will work just a bit harder because of this! :)

On 05 May 2014, at 21:40, Daniel Peebles notifications@github.com wrote:

Yup, I'm on Scala using sbt and have been wishing for a dependency management system like this for a while, so I'm excited :)

— Reply to this email directly or view it on GitHub.

[laughedelic]

cool :+1: I'm looking forward to try it too

[freekh]

Wow, it is cool that you guys are waiting for this! Today I finished the main move and I am working hard on the sbt plugin and automatic the Ivy imports.

[copumpkin]

Great!

[probepark]

:+1:

[freekh]

Hey guys!

We are going to need about 2 more days to stabilise the code. It is unfortunate, but I think it will end up with an alpha that gives a better impression. The reasons are ironically related to Ivy. I have been going through many phases, thinking a lot about how Adept would best integrate with it and trying out different strategies. The problems are related to the unstable nature of Ivy and managing to lock down the moving targets which are Ivy dependencies. Each time I have had the feeling that it has not been a good approach till I finally came up with the one I am at now. The problems ended up being related to how a user would move from a library that was imported to something that is available on Adept. I want this process to be smooth so that when the owners of the library start using Adept and add metadata to make resolution better, the users of the library will be able to upgrade to the new library metadata (and beyond) with a single command (upgrade) even if they imported the data. To manage this earlier the Ivy import would push the imported data to AdeptHub automatically, but this would result in unverified (potentially broken) metadata on AdeptHub. Also I was not comfortable with this, because a user could be using private/commercial dependencies. Therefore I could either force all users to create an account at AdeptHub to be able to import (so that they could manage their imported deps) or simply ignore the problem. None of these where particularly good and I was worried things where simply getting too complicated both in terms of code complexity and in terms of user experience. I think most devs do not really care about dependency management because they usually want to solve their own problems not those of their tooling and all of this would end up with having to understand how Adept works when these problems showed up. The approach I am going for now is that I use per-project, unversioned (from Adept) repositories on imported data from Ivy locally and instead make it optional and easy to contribute the data to AdeptHub. This way the community can make more and more libraries available (as with the approach earlier), but only when they want to. The benefit of contributing for the individual user is that resolution will be faster if they use the same import again. If somebody else has already imported this it can be easily detected and I can make it easy to switch to the Adept libraries when the user wants to. Overall, I think it will end up with a relatively seamless transition from Ivy (though Ivy resolve will take a bit of time the first time) but as I mentioned it is not finished yet, which is why I need a bit more time.

I think Ivy migration is important because I would not use Adept myself if not all the dependencies I require cannot be accessed using Adept and I am assuming that is the sentiment of most people. If the design is bad, I was worried I would end up with having to fight with this the rest of my life (or at least spend more time on it than I want to). The consequences of a bad design choice might still hit me of course, but I felt it was stupid to be know about it and do nothing. Note that I am also planning on adding Bower migration later when I see things are getting stable - my first priority is Ivy. I think it would be cool to have all web assets natively supported (and not through web jars) - in particular because of the multi-dimensional resolution engine of Adept because it would make it possible to specify which browser versions you require or list which ones you support. It is also easier than Ivy because Bower actually uses versioned metadata through Git and therefore is much closer to Adept in that regard.

I can't tell you how much I am looking forward to getting it out myself (and it was really nice to see this issue being created it has helped me focus a lot)!

So that you know: I have put the code related to Ivy and AdeptHub into a different repository because I want Adept to be a project that is not directly coupled with a central commercial entity (AdeptHub). This has worked out for Git and GiHub. The AdeptHub project is still open source and I will give most of it a MIT/Apache 2 type license as Adept once I figure out the details. You can find the code here: https://github.com/adepthub/adepthub-ext.

[freekh]

Happy days! After a couple of weeks now of pretty intense hacking things are finally starting to come together. I think everything is working now and I just need to update the sbt plugin and release it, which I should be able to do by tomorrow unless something comes up.

Sorry for all the delays, it is only me working on this right now, which means that if I have a bad/unproductive day or if I have a client that needs me I will get slowed down.

What you should be able to do in sbt is:

• ah install akka-actor which searches your local repositories and AdeptHub for a unique module called 'akka-actor' , resolves the new graph and creates a lockfile. The lockfile contains the requirements (dependencies) you have, the context (the state at the time you resolved, aka the commit of the repositories, locations of the repositories, the hashes of the metadata you ended up with) and a list of artifact hashes (SHA 256) as well as their download locations. Although that sounds complex, it is designed to be give you maximum speed, because there is no resolution required when you load up you project unless you change something and it makes it possible to do parallell download of artifacts (from multiple locations). It is also designed for maximum reliability because even if you resolve again or with a new set of requirements, Adept will base it on EXACTLY what you had before.
• compile which now will download the artifacts if the hashes do not exists locally.
• ah ivy-install "foo" %% "bar" % "1.0" which imports from Ivy and puts the metadata in a local (unversioned) directory. If a module with the same coordinates is available it will ignore the import and use get the metadata from AdeptHub (unless you force it to import or if you are using a SNAPSHOT).
• ah contribute-imports which uploads the imports to AdeptHub and downloads the versioned metadata from AdeptHub and deletes you local imports. By doing this you do not need the imported metadata if you push you code and it will be more reliable and faster (because reading from Git is faster than the file system and easily cachable) in addition to helping out others so they will not need to do this anymore. On AdeptHub I will make it possible to manage imports smoothly, but for now everything is accepted.

Once this is out the next step for me is to start cleaning up the code a bit, and make it possible to manage repositories/modules on AdeptHub so that you can set binary versions of things. Since metadata is versioned, users (you guys!) will be able to choose when you are ready to update (I will add a notification mechanism as well, so you will see when something new is available). On the sbt plugin I will add an upgrade command, which will take you to the latest binary compatible version of modules that have binary versions. The upgrade command will also replace any snapshot you have with a newer one.

[freekh]

Finally everything is up and running.

If you are interested in trying out the alpha, see install instructions here: https://github.com/adepthub/adepthub-ext/blob/master/README.md

You must expect some quirks (some I have already noticed), but it should be stable enough to use (perhaps not in prod, but for dev).

How it works:

• Use 'ah install' to install modules/dependencies. Currently there is a limited set of modules (the ones needed to build adept and some other random tests), but perhaps with your help there will be more! :) You can install to different configurations by adding the conf like this: 'ah install test akka-actor’. You can also get a specific version by doing this: ‘ah install test akka-actor -v 2.2.1’
• Use 'ah ivy-install' to install using Ivy. It will use your Ivy resolver to do so. It is pretty slow, which is related to 1) it is Ivy… 2) I am grabbing all direct dependencies of all modules and all configurations from everything. When you have finished installing from Ivy, you can do 'ah contribute-imports’. When you contribute something I am storing the zip file with metadata which should enable me to recreate the data you contributed even if I change the formats etc etc...

Then you can do compile etc etc like normal. If somebody else checks out your project, artifacts will be downloaded when they hit something that requires the classpath, without doing a resolution.

I am going to be offline the upcoming week, but do give send me a mail (fredrik at adepthub to com) you have tried it and you have comments (good or bad) or want to get involved.

[freekh]

Closing this as the alpha is out - tell me what you guys think!