Introduction, help on dependency / metadata

[Evan Chan]

Hey guys,

I watched Mark's NEScala video and thought I would introduce myself and see if I could help in various places.

Not only do I have a great interest in seeing this project succeed, but I have pretty relevant experience, having designed and implemented software package management systems in a previous life at VMware.  I'm intimately familiar with the Linux dep formats and metadata (ie RPM,  Debian/Ubuntu/dpkg), as well as many of the internals of package dependency and conflict resolution.   

I don't have that much free time, but would love to help where I can. 

For example, on package metadata and dependencies:  I'm a big believer in not just the standard "dependsOn" relationship, but also adding "conflictsWith" as well as a "provides".  

An example:

Logback provides "slf4j-api", as does "slf4j-api" itself.

Logback conflictsWith: "slf4j-log4j"

The current runtime dependency checking that SLF4J and its modules do should be handled by a package manager.

If a library depends on "slf4j-api", and an app using that library substitutes logback for slf4j-api.jar, the dependency system should be able to resolve that things are still ok.

Anyways, I'll start digging through examples and discussions and see what I can contribute.

-Evan

[Mark Harrah]

Hey Evan,

On Thu, 21 Mar 2013 00:19:44 -0700 (PDT)
Evan Chan <vel...@gmail.com> wrote:

> Hey guys,
>
> I watched Mark's NEScala video and thought I would introduce myself and see
> if I could help in various places.
> Not only do I have a great interest in seeing this project succeed, but I
> have pretty relevant experience, having designed and implemented software
> package management systems in a previous life at VMware. I'm intimately
> familiar with the Linux dep formats and metadata (ie RPM,
> Debian/Ubuntu/dpkg), as well as many of the internals of package
> dependency and conflict resolution.
>
> I don't have that much free time, but would love to help where I can.

That'd be great, thanks!

> For example, on package metadata and dependencies: I'm a big believer in
> not just the standard "dependsOn" relationship, but also adding
> "conflictsWith" as well as a "provides".
>
> An example:
> Logback provides "slf4j-api", as does "slf4j-api" itself.
> Logback conflictsWith: "slf4j-log4j"
> The current runtime dependency checking that SLF4J and its modules do
> should be handled by a package manager.
>
> If a library depends on "slf4j-api", and an app using that library
> substitutes logback for slf4j-api.jar, the dependency system should be able
> to resolve that things are still ok.

Yep, I agree, but I guess you know that from my talk (I think I said that anyway!).

> Anyways, I'll start digging through examples and discussions and see what I
> can contribute.

Sounds good. I'm especially interested in identifying requirements I haven't thought of, things that have and haven't worked or been tried before, and things like that. Certainly proofs of concept (or more than that) are good too!

-Mark

> -Evan

[Evan Chan]

> Anyways, I'll start digging through examples and discussions and see what I
> can contribute.

Sounds good.  I'm especially interested in identifying requirements I haven't thought of, things that have and haven't worked or been tried before, and things like that.  Certainly proofs of concept (or more than that) are good too!

Mark,

I found your NEScala proposal / notes, it seems pretty thorough.  Some thoughts about requirements:

- There is nothing inherently Scala-centric about the idea of adept.  It could help all JVM languages.  So, why not reach out to, say, the Clojure community for example?   (although, assuming parts of the system are implemented in Scala, might hinder adoption in certain circles...)

- I would also reach out to make sure the likes of Bill Venners, as well as the ls.implicit.ly people, are included.

As far as what works: I would say that RubyGems is a really good model, and one of the killer features of the Ruby language / community.   Super easy to use/ publish, very discoverable in multiple ways (CLI, Web, etc.), great defaults.   

Adept needs a killer feature.  But maybe that's the subject of a separate email.

A proof of concept including a basic repo of metadata and some shell scripts to wrap git to demonstrate basic commands should not be that hard.

-Evan

 

-Mark

> -Evan

[Mark Harrah]

On Sun, 24 Mar 2013 00:55:28 -0700 (PDT)
Evan Chan <vel...@gmail.com> wrote:

>
>
> >
> > > Anyways, I'll start digging through examples and discussions and see
> > what I
> > > can contribute.
> >
> > Sounds good. I'm especially interested in identifying requirements I
> > haven't thought of, things that have and haven't worked or been tried
> > before, and things like that. Certainly proofs of concept (or more than
> > that) are good too!
> >
>
> Mark,
>
> I found your NEScala proposal / notes, it seems pretty thorough. Some
> thoughts about requirements:
> - There is nothing inherently Scala-centric about the idea of adept. It
> could help all JVM languages. So, why not reach out to, say, the Clojure
> community for example? (although, assuming parts of the system are
> implemented in Scala, might hinder adoption in certain circles...)

Right, it isn't necessarily Scala focused. It is motivated by problems encountered in Scala, though, and I won't presume to know whether those problems are shared. It is certainly fine to pull people in and it's not like there are restrictions on who can contribute. I think it is important to grow involvement naturally, though. adept is currently mostly vaporware and too many people too early can kill it. Lots of opinions are great on the other hand, so it is a balance.

In terms of implementation, I'd like to see a focus on producing a specification concurrently with an implementation. We're going to want to use Scala, which indeed may be an obstacle for other communities. But, if we ensure that we specify behavior and formats, other languages can use their language for their implementation if they prefer.

> - I would also reach out to make sure the likes of Bill Venners, as well as
> the ls.implicit.ly people, are included.

Doug is on the list. Bill was at NEScala and should know about it, but feel free to directly contact him.

> As far as what works: I would say that RubyGems is a really good model, and
> one of the killer features of the Ruby language / community. Super easy
> to use/ publish, very discoverable in multiple ways (CLI, Web, etc.), great
> defaults.
>
> Adept needs a killer feature. But maybe that's the subject of a separate
> email.
>
> A proof of concept including a basic repo of metadata and some shell
> scripts to wrap git to demonstrate basic commands should not be that hard.

Doug Tangren started on a proof of concept and posted it earlier (see the list archives). Multiple proofs are possible too.

-Mark