Don't wrap bower in protolearningunit.sh (and maybe just drop protolearningunit.sh?)

[wking]

Why not have folks just run bower when they want to perform a Bower function, and run protolearningunit.sh when they want a lesson-manager function? I think keeping the commands separate reduces confusion.

Actually, I think the Jekyll invocation and .gitignore note in protolearningunit.sh would be better placed in the collection repository itself. I can certainly imagine folks wanting to use Bower to build lesson/collection repositories that don't use Jekyll to render their HTML, or that prefer launching Jekyll with other options. In fact, I can imagine folks wanting a single collection that pulls in both lessons designed for Jekyll, lessons designed for Sphinx, and lessons that are just plain text. Ideally we'd recommend a common command like:

$ make -C "${LESSON}" DESTDIR="_build/${LESSON}"

that a collection could use to launch any lesson-specific build framework and install the results to a particular location. It should be easy for folks who aren't using Make to write a lightweight Makefile that does invoke their preferred tooling. That gives folks the freedom to move away from Jekyll/Sphinx, although folks who want automatic GitHub/read-the-docs rendering may chose to stay with an automatically-rendered format for their lesson.

[twitwi]

I tend to agree with the "use the bower command when it is just bower that we want".

For the "where the script should be" (and what it will do in the longer run), we spent quite some time discussing with @r-gaia-cs today, but we'll reconsider it tomorrow morning.

[wking]

On Tue, Jul 22, 2014 at 02:05:05PM -0700, Rémi Emonet wrote:

For the "where the script should be" (and what it will do in the longer run), we spent quite some time discussing with @r-gaia-cs today, but we'll reconsider it tomorrow morning.

Is that discussion somewhere public? Or can one of you summarize the key arguments here?

[twitwi]

The discussion was verbal. We tried to document part of our work on the etherpad but an etherpad is admittedly not the best support for documenting decisions.

The main discussions were about the fact that if we stay on something totally generic, then, there is not much more we can do in addition to what we've done today. If we want to go further, then it makes sense to have a script that really helps in the context of our workflow with lessons.

I'm personally afraid that most people won't appreciate the split in many repositories, and that if we want them to adopt the change, we need to make the new process simpler than the old one (for newcomers).

If you're available any time tomorrow (European time) you're more than welcome in the discussion. After that, I'll personally have a holiday break (I found this tweet amusing https://twitter.com/shanselman/status/487458145728356352 ) but I guess if we transition to this package management, it will need some community voting anyway.

[wking]

On Tue, Jul 22, 2014 at 02:30:46PM -0700, Rémi Emonet wrote:

The main discussions were about the fact that if we stay on something totally generic, then, there is not much more we can do in addition to what we've done today. If we want to go further, then it makes sense to have a script that really helps in the context of our workflow with lessons.

Yeah. I'll look over the docs, but beyond that I think it's just a question of translating the existing bc repo and factoring it out into per-lesson repositories. Of course, the kind of Jekyll build tooling you have in this script still needs to happen, I just think it should happen in the lesson repositories.

I'm personally afraid that most people won't appreciate the split in many repositories, and that if we want them to adopt the change, we need to make the new process simpler than the old one (for newcomers).

I agree that there may be some resistance, but I still haven't gotten many technical/emotional details on why folks don't like multiple repositories. I'm optimistic that a good seed translation into this framework will help cut through the fear, uncertainty, and doubt about this approach.