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 <m...@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
_______________________________________________
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
