Project templates

[Michael Snoyman]

I wrote a blog post a few days ago[1] about how we can represent project templates for our IDEs. I was wondering if anyone had feedback on this (constructive criticisms are great, but even "that sounds fine to me" feedback is welcome). I guess the two main questions would be (1) would other IDE projects adopt this template system and (2) would people looking to create templates adopt it?

One thing I definitely want to try to avoid is needlessly reinventing the wheel. Needlessly is important here: if we're reinventing the wheel for a valid reason, I think we should do so. But if there's prior art that actually fits our use cases, I'd rather use that. The only example of prior art I've seen mentioned[2] is giter8[3]. Without having personal experience with it, here was my assessment:

I agree with not reinventing the wheel, but giter8 seems like it doesn't solve our problems very well:
1. It's ill-suited for creating a non-Java implementation.
2. It's tied explicitly to Github.
3. It doesn't handle conditional files/content.
4. It has a prebuilt list of questions to ask users.

If anyone has actual experience with giter8, I'd really like to hear their input. And if there are other possible solutions that I've overlooked, please bring them up.

Michael 

[1] http://www.yesodweb.com/blog/2012/09/project-templates

[2] http://www.yesodweb.com/blog/2012/09/project-templates#comment-655705286

[3] https://github.com/n8han/giter8

[Dan Burton]

Other prior art in this area would have to include Clojure's leiningen[1]. lein fills the role of cabal, but apparently also has some sort of plugin architecture that lets you generate a new project template with:

    lein new [TEMPLATE] NAME

lein is wildly popular among clojurists, but I doubt it can be easily adapted for Haskell use. I think that creating a command line tool on top of cabal that adds features like this would be the best approach. Then IDEs could simply invoke the correct command to generate the correct template.

As a side note, rather than using JSON, I think Haskellers would find XMonad-esque Haskell syntax config files more appealing.

[1] http://leiningen.org/

-- Dan Burton

--
 
 

[Michael Snoyman]

On Fri, Sep 21, 2012 at 6:50 PM, Dan Burton <danburt...@gmail.com> wrote:
> Other prior art in this area would have to include Clojure's leiningen[1].
> lein fills the role of cabal, but apparently also has some sort of plugin
> architecture that lets you generate a new project template with:
>
> lein new [TEMPLATE] NAME

I found this page[1] but it doesn't really give a lot of information
about the format they're using for storing the templates. But it
*seems* like it doesn't provide any kind of conditionals or user
input.

[1] https://github.com/Raynes/lein-newnew

>
> lein is wildly popular among clojurists, but I doubt it can be easily
> adapted for Haskell use. I think that creating a command line tool on top of
> cabal that adds features like this would be the best approach. Then IDEs
> could simply invoke the correct command to generate the correct template.

Actually, I think I'd like to avoid exactly that. We're currently in a
system where everyone is creating new command line tools (myself
included) that add on behavior we want, and then IDE authors are
required to figure out the command line interface of each individual
tool. I'd be much happier if everyone (again, myself included) instead
provided libraries that, as IDE writers, we could just call. And this
isn't just an advantage for IDEs, but for *any* place where we want to
provide this functionality. Advantages to a library include:

* No concerns of users not having PATH set correctly
* Doesn't cause a problem if the user deletes this seemingly unrelated
file, or never installed it in the first place
* Much more type safety: calling an executable is the equivalent of
`[String] -> IO (ExitCode, String, String)`. I prefer meaningful type
signatures, which will refuse to compile when an API is changed.

>
> As a side note, rather than using JSON, I think Haskellers would find
> XMonad-esque Haskell syntax config files more appealing.

Why? I'm not recommending that people *edit* the JSON files, they
would be simply for serialization. It would certainly be possible to
create a tool that converts from Haskell syntax to/from JSON: it would
essentially boil down to `show . decode` and `encode . read`, but JSON
has the advantage that the libraries for dealing with it in almost
every language (include Haskell thanks to aeson) are very well
developed and mature. If someone decides to create a Visual Studio
plugin and wants to generate Haskell project templates in C#, I think
they'd be annoyed that they need to write a parser for the
XMonad-esque config file.

Michael

> --
>
>

[Montez Fitzpatrick]

Late on this one and I hate to say a dirty word but it seems to me like you are wanting to model it after something like Maven, Ivy, Buildr or SBT?  Admit-tingly, I've not used any of these in a long time since I was heavily involved in learning Scala.  I believe that how it serializes is a tertiary concern to what you want it to do. I may be offbase and I hope to not offend anyone but Java definitely has overly complex software modeling concerns, and they've built tools to fit that workflow.  

I could see advantages in a templating tool modeled after something like this, such as the composition of the various types of development sandboxes, basically one command set that would cover (cabal-dev, yesod devel, virthualenv, etc) just to throw something out there.

Perhaps a repo system that was Git, Darcs, Mercurial aware could be a game changer.  Probably should include some of the old guard versioning systems as well, I would see something like this not just appealing to new Haskellers but as a catalyst to Haskell trickling into an enterprise project or two.

[Alexander Kjeldaas]

Please excuse some ranting, but I've been hacking on haskell-mode these last days, and one feature that is desperately needed in a project definition is how the mapping between code and tests are supposed to be done by an IDE.

I've looked at yesod, snap and other projects and they are all doing it differently.

There should be a way to say the following to the IDE:

"If I'm editing src/My/Project/MyModule.hs, expect to find tests at tests/My/Project/MyModuleTests.hs,

if not, in tests/suite/My/Project/Tests.hs, or if not, try ..."

Likewise, the test system should be specified so the editor can create a boilerplate test file.  Creating templates and filling them is trivial using for example yasnippet in emacs, but without a standard layout, it's meaningless.

A naming convention for tests should be specified so the editor can jump to a relevant test or create a boilerplate test.  Without knowing which test system is in use, this is also meaningless.  What should the boilerplate look like for a fresh test file?

This was all incredibly simple to code up in emacs when I worked at Google where everything was standardized.  I would simply do a C-c t and get to the test, or a boilerplate test file would be created, or even a boilerplate test for the given function.  I have this in my personal Haskell projects as well, but I'm sorry to say so, but whenever I dive into other projects like snap or yesod, it's incredibly time consuming.

The absolute maximum amount of time it should take to create a "null-test" for a function is 1 second.

Thanks for taking the time to read my rant.

Alexander

[luc taesch]

Scaffolding helps, by providing, structure and content. They guide .


- scaffolding are Models , and if we stretch the analogy , like
wizards, where we would have stripped out the GUI , and keep the M and
C in MVC ;
the command line is the Controller, the templates the Model ( and GUI
the View).
they are used BEFORE the FIRST build, to sketch out a project

-and AFTER the build,
Cabal or Make files are encodings dependencies between these files when
they are built.,


the link here is temporal, first we set in place some Models, we fill
them , and we build. but we express a similar things, we speak a
similar language ( even if the syntax if very different today)

I see the connection in the two, as the result of (E)DSL:

- we could imagine the scafoldings generated out of a DSL
- we could see a build system as a DSL too.

Recently I read about [Shake], as a DSL for a build system.

Proposition:

- could we imagine re-inventing the (round) wheel by re-using [Shake]
to generate the building of the scaffolding ? or using the same DSL to
design and produce the scaffoldings , and build the system afterwards.

- could we see that out of Haskell semantics, we will soon generates
many languages out of the semantics/ types (JS in the browser (Fay),
Markdown in docs, or generated contents, SQL, etc...) [2] ?

- Then it would be nice to see these two things are similar

in that way, we will have unified the design-build continuum, or
started reduced the Gap between for-thinking /doing / reusing ..(the
Mind jumping between Future/ Present Past)


[Shake]:(http://community.haskell.org/~ndm/downloads/paper-shake_before_building-10_sep_2012.pdf)
[2]:http://hub.darcs.net/stepcut/mastermind