[PROPOSAL] Don't replicate Leinigen's project structure

[arrdem]

I would propose that, rather than replicating leinigen's defproject form, that instead Dust take a more data driven approach to project specification while we/you still have the chance.

Defproject is nice and familiar to be sure, however I would argue that we can pack all the same information into a simple map (which is what leiningen builds internally anyway). Furthermore, as such a map is data and data alone it becomes easier to automatically manipulate project files with external tools.

Just an idea I've been kicking around since Dust was proposed. I don't have time right now to hammer out a patch (finals are next week) but I'd be curious to see what y'all think of this.

[heyLu]

While I like the idea of tools being able to manipulate the project, this isn't possible right now because we can't read files yet. So far, I didn't add file reading because I hoped libuv would handle that. I'm not sure whether we should just add slurp and spit for the time being or wait until we can use libuv via ffi.

[bmillare]

I second arrdem's approach. As an appeal to authority, datomic is more like this, using data as specification, rather than relying on the defproject form makes it easier to deal with in the future.

Also with the data spec approach, we are not limited to specifying the information as a project file but in any format, like a database, or json blob, etc.

[maddie927]

Maybe take a little inspiration from Boot where Leiningen is lacking

[heyLu]

I've created a pull-request (#14) that uses a project.edn file instead of our current defproject approach.

Feel free to play with it for a bit. (Everything should be the same, but with the nice feeling knowing that the system is more declarative. :)

[heyLu]

I've just merged #14, so I'm closing this issue now.