Launchconfig class

[eugene yokota]

Hi guys,

Extending the idea of overriding the "version" entry of launchconfig,
I've added a new class called [Launchconfig][1],
which let's you CRUD an entry by calling `update` method with a
ConfigEntry object. This then returns another immutable instance of
Launchconfig.

Here are two new command line options I just added (which may or may not stay)
called --local and --no-local:

opt("local", "include local repos", {
config = config.copy(entries = config.entries :+ InsertLocalRepository)
})
opt("no-local", "exclude local and maven-local repos", {
config = config.copy(entries = config.entries ++
Seq(RemoveLocalRepository, RemoveMavenLocalRepository))
})

config.entries is then folded with _ update _:

val modLaunch = (launch /: entries) {_ update _}

The idea of --local may not pan out, but modifying launchconfig is now
matter of defining the ConfigEntry object if another similar idea
comes up in the future.

InsertLocalRepository looks like this:

trait RepositoryConfigEntry extends ConfigEntry {
val section = "[repositories]"
val value = None
}

case object InsertLocalRepository extends RepositoryConfigEntry {
val key = "local"
// this puts this entry ahead of all other repos
override val position = Insert
}

-eugene

[1]: https://github.com/n8han/conscript/blob/master/src/main/scala/launchconfig.scala

[Nathan Hamblen]

Is the idea that Conscript would fully generate the launchconfig instead
of just replacing strings, caveman-style?

Nathan

[eugene yokota]

You mean represent configurations `launchconfig.scala` or something
and `cs` would generate `launchconfig` file dynamically?
I don't see how that's geico, so either it's not, or I am one of the cavemen.

-eugene

[Nathan Hamblen]

I'm saying the current method (my method) is caveman style, and you seem
to be working on something more sophisticated. Also, I've reached my
email quota for the weekend and the rest is just going to be (more)
gibberish. :)

Nathan