also see support wagn as rails add-on gem

---

maybe we should fold these two cards into one? It seems they are talking about the same idea, no?

---

the other is specifically just about installing wagn into rails. that may depend on this, but it's not a driving force.

---

I've gotten a simple gem working. You can't do wagn new or wagn server yet, but, I got sites to work! Code is here, but you would need a bit more than that to get things working. I'll see if I can get "new" and "server" up next.

---

It is really cool that you are working on this.

 

I think we need some deeper thinking, though. We need to implement generators, and I'm not quite sure yet about the best organization. I think you would first:

rails generate my-wagn-app

Then add wagn

gem install wagn-core

gem install wagn-standard

Then add it to your app (from the my-wagn-app directory:

rails generate wagn

Now customize by adding local mods and etc.

Or, to just run it as is without any mods:

rake wagn:install

rake wagn:create

 

Note that the wikirate repo is incomplete, there doesn't seem to be a way to add the codenames for the wikirate mods. We should have a third repo that contains a standard app, the result of doing the above with no mods. I should be able to copy in my database.yml, wagn.yml and do a rake db:migrate and be up and running again. I think it would be best to make the main wagn repo be this third part and make new ones for the other (one or two, could be just one to start). That would simplify the upgrade path for cldstr too. The new version would have the app updated from the standard repo, and the new gems would be in with all the other gems for deploying.

---

Here's where we're headed:

 

1. gem install wagn # (this will install the wagn gems and all its dependencies, including rails, smartname, and, if we decide to go that route, wagn-core and wagn-standard. I see no value in conflating that issue here, by the way. let's punt on that discussion)

2. wagn new mysite # I've already got this working. it piggybacks heavily on the rails commands, and like rails new it uses a generator, but there will be NO explicit rails commands involved in the process.

3. rake wagn:create # (from mysite dir) there's no need for wagn:install any more; 'wagn new' handles all of that. I'm even going to make this command work without editing yml files by getting sqlite to work

4. wagn server

 

I've actually gotten this all working on my new rootflip branch, which I started yesterday. You can look at the readme on that branch for something similar to the above. The "rootflip" idea was to make it so that the new wagn apps are, themselves, applications with their own boot, environment, and application files.

 

It's actually pretty cool. To try it out, you would need to do something like this: " gem build wagn.gemspec ; gem install ./wagn-1.12.5.gem ". That should give you access to a wagn executable.

 

It basically works, but I have some work to do to on environments and such.

 

Key points:

1. this is NOT a gem to be used as a rails plugin. We may do that at some point (presumably with engines), but for now this is to support wagn apps, not rails apps.

2. users should not have to use any rails commands to get this working

3. we don't need all the rails directories (eg app, db, vendor, and arguably even lib, since the libs should be in mods). Our generator doesn't use those

4. this should simplify installation, not complicate it.

5. regardless of how we end up organizing gems in the long term, there will likely always be one "wagn" gem just as there is one "rails" gem. That rails gem is very minimal; all the work is done in railties, activemodel, activerecord and all the rest. I do think we'll break things down further soon but don't want to go there yet.

 

---

Sounds like you are making a lot of progress, I'll have to catch up ...

---

Ok, but you have to manually build the gem and install it from a local file?

---

Not sure if you saw my latest PR, was playing with writing some specs (for loader and set). Then I was doing a spike to see if we could really separate core (I know separate discussion). I think it will be pretty hard but worthwhile at some point. Very few of our specs are really very stand-alone. Lots of stuff depends on the standard chunks (Include and Link) as you might expect, and some of the more basic types. Like all internal refactoring, can be hard to justify spending the time.

 

Part of my motivation is that I'm needing to show some of my work for a possible interview at reverb.com. I'm not really actively looking, but I have talked to three possibles last week, each interesting in its own way.

---

I guess building and installing the gem is pretty easy:

gem build

gem install

Maybe one of us should add that to the README

---

Great that cucs are running again. I get two failures, one spec, one cuc, do you get the same or is that just my instance. Probably not any new migrations, etc.

---

Hmm, almost working. So, wagn is really rails command with some extras? BTW, errors still say 'rails' in the help-text.

 

But the problem I have is it doesn't seem to be reading the database.yml correctly. First I used an existing one because I wanted to use my current db, but even when I put my values into the generated files it says that adapter isn't specified.

 

Also, need to remove the :path => from the Gemfile. That's for dev when you don't want to repeatedly install the wagn gem. If you generate the gem and install it, the bundler finds it correctly.

---

It still should read wagn.yml from config/, right? Seems it isn't loading that file now.

---

Looks like it gets it from the gem config dir, that doesn't seem right. Was that intended?

---

As soon as we publish the gem on rubygems.org (which I'll probably do tonight), nobody other than a developer will ever have to do "gem build". So, no, that should not be in the README. Similarly, we'll obviously get rid of the path call.

 

Re wagn.yml (and Wagn::Conf in general), I started phasing that out yesterday in favor of using the local config/application.rb file. We couldn't do that before, because application.rb was part of wagn, so we didn't really want users editing it. But now it makes total sense to use that as the app configuration mechanism.

---

Ok, makes sense. I merged this into my PR branch, but didn't push yet. Standard is to leave it from develop, and I won't push the rootflip merged version until and unless you merge it, but I'm thinking that those changes are more important as we continue this gem work. Logically, it would just load mods from each gem that has them, and finally from the app_root/mods dir, and maybe we don't even need that configuration.

 

I think I'll try to make a custom app repo for that live-edit spike I was playing with. There are some interesting questions raise, particularly for "while developing". For example, I may want to play with an app that uses my smartname mods for date keys, so I can make a wagn(gem) branch that includes my special dependencies and just update my apps Gemfile. Same with when I want to work with a wagn gem from a not-yet merged branch.

 

I guess if you are going to phase out wagn.yml soon, it doesn't matter, but maybe you should change it to look for the conf file in the app-root, or maybe app-root, then gem-root? Depends on the timing whether this even makes sense.

---

Noticing a couple more things:

1) Have you thought any more about javascript assets? My app wants to add it's own js files.

2) What about content processing? clean! is still a wart. I once moved it to split it from the Content class, and I still don't like it there. This is a more general thing of post processing (for content here). Just overriding the tags and attributes for standard clean! processing is one thing, but I want to add tags and attributes for fine-grained references supported in the live-editor js. In my spike, I do this processing in clean! because I don't really want to scan for tags twice (efficiency), but I can see that it might need to be a separate processor.

We don't really have a place for this in mods. I could just override clean! by putting a new def in an all set and open class Card::Content, and I guess I'll give that a try.