Distributing Fubu.exe and "Fubu New" Project Templating

[Mike Murray]

I rebased the Fubu New pull request in regards to the latest on the master branch. As I was looking at the pull request, I tried to figure out what our strategy is for distributing Fubu.exe.

It appears that currently it is done via a "tools" folder in the FubuMVC.References NuGet package that finds its way onto a user's machine in the "packages" folder. Is this good enough? Would we prefer it get moved somewhere else more easily found? What about installing/"installing" it somewhere (maybe somewhere in User profile/AppData) and then throwing it in the user's PATH environment variable so it's accessible anywhere? Is this a good case for looking at something like Chocolatey?

As for Fubu New project templating in that executable, it is designed to be able to take a path to a zip archive or a Git repo containing a template, or to use a default template we provide and that the executable automatically loads up. There are a few assumptions made in what the default template should include, and I thought I would run them by the whole group for consideration.

1. The standard Models, Views, Controllers folder structure is laid out for the user. There are certainly other (arguably better) conventions that could be encouraged instead, but a case could be made that the former convention is the most standard and familiar to transitioning users. Either way, I would imagine veteran users of Fubu would be coming up with their own templates anyway, leaving the default one to be used most likely by the more novice FubuMVC users. So to me it seems to be a discussion about providing new users with a more familiar setup vs. encouraging a more "Fubu way" of doing things (e.g., The Handlers convention is often seen as a more SOLID way of looking at MVC controllers).
   
2. Spark view engine brought in by default. This should be encouraged over WebForms any day. Am I right? (Though this probably fits with the same "familiar vs. encouraged" argument as above...maybe not, I don't know)
   
3. Basic Diagnostics by default. Advanced instead, I presume? Drop its bottle into fubu-content in the template?
   
4. Should the GettingStarted bottle be there as well then?
5. The way the Fubu dependencies are being brought in is to build up the template itself during build time, grabbing the latest DLLs as they are built and copied into a lib folder in the template folder structure. It is nice that the template will always be updated with each CI build and therefore the default template that gets distributed alongside the Fubu.exe will be updated. But I haven't yet checked how it is getting the other dependencies it needs, like FubuCore or HtmlTags or Spark. I'm hoping this route ends up with same versions of those dependencies as you would get if you pulled down Fubu from NuGet; I don't think we'd want the default template moving ahead of NuGet in that regard. So yeah, it's cool the build is keep the template updated, but my next point may counteract this advantage...
   The other issue to consider is that this way of referencing the framework as currently set up in the default template will not allow a very updateable solution going forward for the user. I'm thinking it would be nice if the structure of the dependencies in the template mimicked what NuGet would have done itself, so that within Visual Studio all NuGet tooling would work and alert you to updates to your packages as time passes.

Ok, I think that's probably good for now. Should lead to a good discussion. Ready, set, go.

Mike Murray

@mkmurray

http://murrayon.net/

[Joshua Arnold]

I say we keep it where it is within the "tools" folder until we come up with something else that will work for Windows and Mono. 

+1 on the basic Models/Views/Controllers. Throwing everything together or introducing the handler-style stuff might be too much for a new user. And as you said, they can make their own templates (would be nice to be able to share these somehow)

+1 on Spark engine by default

+1 on Advanced Diagnostics and GettingStarted

With regards to dependencies...

I like that the dependencies are alongside Fubu.exe to keep things at the proper version. That's good and all for the tooling aspect, but I absolutely think that the dependencies within the template need to be brought in via NuGet. To avoid that biting us in the rear, we may want to have the template lock us into a version (although the argument can be made that we'll be bitten by that just as well). Not leveraging NuGet within the templates just doesn't seem like a good idea, in my opinion. However, that should be a PER template problem, should it not?

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/Vvg_Sn_IeGoJ.
To post to this group, send email to fubumv...@googlegroups.com.
To unsubscribe from this group, send email to fubumvc-deve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.

[Jeremy D. Miller]

On:

1.) Man, I really don't care for this.  It just screams "MVC" and I don't think that's a good thing.  It's a waste of time for people to use FubuMVC like it's ASP.Net MVC

2.) I'd rather there be an option for "application", "vertical slice", or "doesn't need any kind of view engine".  Most of the usages for fubu new I have backlogged in my own mind won't require Spark at all

3.) & 4.) See above.  What about wanting to set up a new Bottle that just defines a new reusable html convention?

On #5, I at least want an option that creates a "ripple-ized" solution for FubuMVC itself and the other dependencies.  
 

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

---

From: Joshua Arnold <rncod...@gmail.com>
To: fubumv...@googlegroups.com
Sent: Wed, November 9, 2011 11:37:04 PM
Subject: Re: [fubumvc] Distributing Fubu.exe and "Fubu New" Project Templating

[Michael Murray]

On Thu, Nov 10, 2011 at 8:03 AM, Jeremy D. Miller <jeremy...@yahoo.com> wrote:

2.) I'd rather there be an option for "application", "vertical slice", or "doesn't need any kind of view engine".  Most of the usages for fubu new I have backlogged in my own mind won't require Spark at all

So do you favor exposing several command-line options around this as opposed to creating several of your own templates? Or perhaps you are suggesting several default templates instead of one?

As for every usage I can think of how I would use Fubu New, Spark would need to be in almost every one of them. I think this just underscores how differently Fubu New would be used by everyone. The tough part then, is to decide what the defaults and most common uses should be I suppose.
 

On #5, I at least want an option that creates a "ripple-ized" solution for FubuMVC itself and the other dependencies. 

I think I know what you mean...You want a Fubu New'd solution that handles it's dependencies in the same way the Fubu source itself does? I have a lot more to learn about Ripple in order to understand what this would entail. My only concern is wondering if this is the most helpful to the average user of Fubu, or if VS NuGet interaction would be best.

Perhaps I'm off base here. Would we rather encourage what's best over ease of transition? Do we want people to be able to hit the ground running fast or help them understand a newer, better way of writing web app code that MS doesn't even try to encourage? Or am I pitting these two things against each other when in reality, they're not as much at odds as I am supposing?

[Joshua Arnold]

I think the original intent of Fubu New was to bring us the functionality that NuGet ended up providing for us: allowing people to get up and running with minimal friction. Now that we have that, *I* think Fubu New is more about easing the friction for teams already using Fubu. 

> "Or perhaps you are suggesting several default templates instead of one?"

It seems to me that this is the right approach. Provide several default templates and let teams go from there. Assuming we have strong templating support, there's no reason to delay this going into master since we can just build the templates ourselves and share them when they stabilize.

> "I at least want an option that creates a "ripple-ized" solution for FubuMVC itself and the other dependencies"

This is all about a repo setup more than anything and again is just a template -- at least, it *should* be.

I say we bring it in and we'll start hacking away on templates.

[Michael Murray]

Maybe we just enter the Kanami cheat code to unlock Fubu New Super Invincible Mode :)

[ahjohannessen]

I agree with JDM on 1) 

"Or perhaps you are suggesting several default templates instead of one?"

I think we need support several as there are different kind of target users and usages (package, extension, app and so on).

[Jeremy D. Miller]

I think having at least a couple default templates out of the box sounds like a winner to me:

1.) New application

2.) Bottle with UI

3.) Bottle sans UI

In regards to the ripple thing, how about you happily ignore that for right now, but I add that in as an option later (or talk someone thru it)?
 

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

---

From: ahjohannessen <ahjoha...@gmail.com>
To: fubumv...@googlegroups.com
Sent: Thu, November 10, 2011 9:58:34 AM

Subject: Re: [fubumvc] Distributing Fubu.exe and "Fubu New" Project Templating

I agree with JDM on 1) 

"Or perhaps you are suggesting several default templates instead of one?"

I think we need support several as there are different kind of target users and usages (package, extension, app and so on).

--

You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.

To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/oRR0KJPruQIJ.

[smerrell]

+1 for not using the Model, View, Controller folder structure

+1 for updating the templates to have the packages.config in the right place. That should let VS and NuGet pick it up, though I'm not sure how VS handles when you have the packages.config but none of the DLLs. If that works out, it would be better to not zip up the DLLs with the template.

+1 Spark / Advanced diagnostics in the default

As for 2 - 5 Those should be as simple as creating several templates we deploy and possibly updating the command slightly to let you use a default template name so you can pick which you'd like (i.e. fubu new bottle <name>, fubu new application <name>, fubu new support-bottle <name>) or even adding something like a -type enumeration. Probably would want to add a little help and documentation on what's in those defaults.

After that creating your own templates should be easy. For a team, I would think the best course would be to put them up as Git repositories and then use them that way. I have a few ideas how to enhance the git support for fubu new (using branches) but I've been waiting till it gets pulled into master :p

[smerrell]

Shoot, if it gets pulled into master soon, I could probably add the multiple base templates pretty easily tomorrow. If we added a -type argument and used an Enum then we get nice help text. Something like

fubu new -type (application | bottle | supportBottle | etc) <name>

That wouldn't be too hard to add.

[Joshua Arnold]

I hear that two of the Extend guys have commit rights...;)

--

You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.

To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/A006d2kvYdYJ.

[Rob Reynolds]

Addressing the distribution of fubu.exe: 

If you have chocolatey, calling 

cinst fubumvc.references 

from the command line already "installs" fubu.exe on the machine and puts it on the path. I attached an image of that experience (if that doesn't work, I put the image on dropbox: http://dl.dropbox.com/u/9391884/fubuchocolatey.png).

The ideas behind chocolatey allow for you to release a tool simply by including an executable (and its required references) in a nuget package.

It might be an idea for the fubu executable to have its own nuget package. Whether it is released on nuget.org or chocolatey.org is up to you. If it has a use inside of projects as well as outside of projects (as many tools do), I would say to keep the package on nuget.org. One could also dual release to both chocolatey.org and nuget.org, I do that for RoundhousE. The purpose of that is only to increase awareness for both communities.

With your current path, chocolatey already supports the machine type installation. If you decide on a different path, it's possible that chocolatey can support that as well. Whether you decide to make that a recommendation for users though is up to you. :D

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[ahjohannessen]

@Rob sounds smart. Does it work with Mono?

[Robz]

Unfortunately it does not at the moment.  It is meant to address a deficit in windows with machine package managers.

That said it could technically be made to work with environments supported by mono, but it could be an undertaking (one that I am currently looking at doing anyway for various reasons) since it is  currently written in & leverages powershell.

I may be behind the times though and someone may have already taken the recently open sourced spec for powershell and made it work with mono. In which case I could say that it does if nuget.exe does. ;)

On Nov 10, 2011 12:08 PM, "ahjohannessen" <ahjoha...@gmail.com> wrote:

@Rob sounds smart. Does it work with Mono?

--

You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.

To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/gIK4k9l8R_kJ.

[Mike Murray]

Ok, I pushed the pull request into master now. It comes with a "defaultTemplate" for now but we built-in the ability to start making other default templates under fubuTemplates that would ship with Fubu.exe via the FubuMVC.References NuGet.

Sam was going to take a stab at some other default templates. I figured out what needs to happen to get the template to produce a codebase in which VS is fooled into thinking it was the one that put the NuGet references into the solution; but this isn't done yet, and I'll have to work on that.

Also I found an issue with regard to referencing Spark in your site and having the GettingStarted and Diagnostics bottles present. If I have the "this.UseSpark()" line in my FubuRegistry, then the default / route renders nothing, though it thinks it should go to the GettingStarted page in Diagnostics. However, if I remove that line from the registry, then the default / route correctly loads up that nice welcome page from Diagnostics. Any ideas on this? Josh?

And one more thing, the build failed on build.fubu-project.org (build #638). I can't figure out why ("it works on my machine"). :) It's in regard to using NuGet to get the dependencies to shove into the template(s). Do we need to do a clean checkout or something (though I can't think why we'd need that)?

Sorry for breaking the build; I can't put my finger on it, and I need to get home before the wife kills me! :)

[Jeremy D. Miller]

Cool beans Mike.  I won't get to it til tomorrow afternoon at the earliest, but I'll look at the build.

FYI, I know what to do to finally eliminate the "this.Spark()" thing once and for all.  I think I'll push that this weekend too.
 

"Ok, I pushed the pull request into master now. It comes with a "defaultTemplate" for now but we built-in the ability to start making other default templates under fubuTemplates that would ship with Fubu.exe via the FubuMVC.References NuGet."

I like that.  We'll grow the others soon.  I've already got some things I want to do.

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

---

From: Mike Murray <charlie...@gmail.com>
To: fubumv...@googlegroups.com
Sent: Fri, November 11, 2011 7:44:18 PM
Subject: [fubumvc] Re: Distributing Fubu.exe and "Fubu New" Project Templating

--

You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.

To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/gInDuL3CPdIJ.