[PATCH 4 of 4] setup: add gearbox command to setup front-end

[Mads Kiilerich]

Thanks. I really appreciate having a second opinion and different take 
on this. That makes it easier to discuss ;-)

My questions are mainly about verifying that this "MVP" is a stable 
foundation and establishing a shared vision of how this can work for the 
next steps we know are coming.

> # HG changeset patch
> # User Mads Kiilerich <mads at kiilerich.com>

This patch seems to only reuse a few trivial lines from me. There is no 
need to give me credit for this.

> The approach implemented by this commit is to add a custom gearbox command
> 'setup-frontend' to run the required commands. This single user-facing
> command can internally run various steps as needed. The only current
> requirement is the presence of npm and an internet connection.

What is this command really about, and what is the scope of it? I guess 
it essentially is something that prepare all the static files that can 
be served directly by the web server ... and perhaps even be served by a 
front-end server or put on a CDN?

Instead of augmenting the source directory, it should perhaps fully 
generate a target directory from scratch, populate it with npm output 
and copying additional files from the source tree. Neither Kallithea 
source directory nor npm installed stuff should be directly exposed by 
the web server.

It should probably be possible to give the directory to the gearbox 
command (and/or configure it in the app config) so it doesn't have to 
clobber the site-packages directory but can be installed in a different 
place with different permissions and security posture.


Is "setup front-end" descriptive for what the command does? Is it really 
a "setup step"? Or is the role more similar to "make-config", and could 
be named "make-frontend"?

I think there are valid use cases for separating the on-line "download 
and install npm stuff" part from an off-line "build from source and 
downloads" parts. Perhaps give the gearbox command options for just 
running one of these parts? I guess the on-line part is setup-ish, while 
the off-line build part is more make-ish ...

I wonder about the omission of '-' in 'front-end' in the command name 
that already contains another '-'. Which of the spellings would be least 
confusing?

Perhaps name the command "front-end" (with "--download"/"--install" and 
"--build" and "--path=" options)?

> For now, this will just create/update style.css ... but currently probably
> without any actual changes.

How will this gearbox approach work with other use cases as outlined on 
https://kallithea-scm.org/repos/kallithea/pull-request/137/_/remaining_bootstrap_related_stuff_v3#C--b9cfc7f2cdf7 
: Generated files (pygmentize) and automatic rebuild (kind of as server 
--reload) and minification and non-minified development mode (if 
relevant?). And JavaScript handling? Can we have a PoC that show how 
that could work?

I don't think I would like to have the application run this 
automatically at run-time, but could it be feasible to let the 
application fail to start if front-end code hasn't been generated or is 
outdated? (That kind of goes in the opposite direction of allowing it to 
be hosted elsewhere ... but that could be a special case.)

> +class Command(BasePasterCommand):
> +    """Kallithea: setup the front-end (JS and CSS)"""

So far it only does css - no js. But that should hopefully change soon.

> +    takes_config_file = False
> +    requires_db_session = False
> +
> +    def take_action(self, args):
> +        rootdir = os.path.dirname(os.path.dirname(os.path.abspath(kallithea.__file__)))
> +        print "Running 'npm install' to install frontend dependencies from package.json\n"

We should be consistent in the spelling of front-end (when possible - 
identifiers and module names might have to be different).

/Mads