Generate archive for support scaffolding command

[kination]

How do you think about making package for scaffold support? For example, phoenix are supporting phoenix_new command by installing their package for simple scaffold. I just tested by installing archive file. It shows command like this.

$ mix --help
...
...
mix sugar.gen.controller # Creates Sugar controller files
mix sugar.gen.router     # Creates Sugar router files
mix sugar.gen.view       # Creates Sugar view files
mix sugar.init           # Creates Sugar support files
mix sugar.scaffold       # Creates Sugar controller, model, and view files for a resource
...

I could see command update like above. As you know I'm still new in sugar/elixir so I'm not sure this suggestion has been discussed before or not. Could you let me know how you think?

Thanks.

[YellowApple]

It's a possibility. I personally gravitated to Sugar instead of Phoenix precisely because (among other reasons) I didn't have to install some extra package first before I could generate a Sugar app.

Of course, back in those days Phoenix didn't have its current mix archive.install $SOME_URL_ON_THE_WWW installation method; instead, you had to clone Phoenix's GitHub repo, then build Phoenix and run a Mix task from within the repo to generate a Phoenix-enabled application. In that context, Sugar was actually easier (since you just had to add the dependency to an existing project and run mix do deps.get, deps.compile && mix sugar.init).

Nowadays, it's still easier in some respects, particularly if you're adding Sugar to an existing application. In fact, Sugar is sufficiently-minimal that I typically don't even feel the need to use the existing scaffolds; defining a new controller, for example, is still just a matter of adding use Sugar.Controller to a module, and views are just ordinary EEx or Calliope/HAML templates. For that reason, it's not an especially high priority for me personally (@slogsdon might disagree here, though; can't speak for him).

That said, it would still be a welcome addition, and would be an excellent learning opportunity if you're up for it. The Phoenix installer and Sugar's scaffolding tasks would be a good starting point for creating a new Mix application that could be globally installed via mix archive.install.

Pinging @slogsdon for yea/nay on this, but if you were willing to give this a whirl, I'd be in favor of incorporating it into the "sugar-framework" org and mentioning it as the "quick and easy" installation method (alongside the current process, which would still be recommended for those looking to add Sugar to an existing application or for those like me who prefer a more do-it-yourself approach).

[kination]

@YellowApple Thanks for quick response! I could understand what you are meaning of. Actually, the motive part that I become interest in sugar is it is minimal and light framework. I am thinking relation of phoenix and sugar as django and flask in python, so it is great to make this project more lighter. Reason I thought about this is, I was thinking of way to make it more easy and accessible, and one of it is offering simple scaffolding. Let's think about this. Thanks!

[slogsdon]

To add to what @YellowApple mentioned, I had initially created the sugar.init Mix task to reduce the complexity of getting started. Before Mix's archive's received some love, building and installing one meant creating a local copy of the archive's project and pushing the responsibility of building the archive on the developer wanting to use it. Leveraging a Mix task like sugar.init to scaffold an existing project by adding a dependency a developer would need to add anyways was a simple and effective compromise.

That being said, I wouldn't be opposed to having a Mix archive to expose the project scaffolding globally, as long as the Mix archive only contained project scaffolding tasks. Are there ways of hosting these through Hex yet, or would we be required to self host these archives + updates (e.g. through GitHub releases)?

[YellowApple]

Apparently there's some support in Mix for installing an archive from a Hex package. If that does what I think it does, then we could distribute a sugar_installer application or somesuch on Hex and make it installable that way.

Else, using GitHub releases seems to be the most viable approach, and is in line with how Phoenix does it.

[kination]

@slogsdon @YellowApple While I'm reviewing documents for starting and working on samples, it looks like it is enough for now to let in current state about this. Going with sugar init seems not quite bad. Maybe we could think about it again while this project is going on, and I'll re-open again.

Thanks for conversation.