Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
True. Things have grown historically. Though there are several categories of commands, broadly:
Have to think what the best strategy is. We could move everything to
Not for this issue: Would things help if we move to Django at some point? Looks like lots GHC stuff is explicitly programmed (forms, DB upgrades, possibly other commands) that is automated or web-based in Django.
I don't think using paver is a good idea. It's purpose is a bit different, and while it can be used to manipulate the app, it's not suited well to build composed apps. Flask offers cli application facilities, uses
In general yes, although it's better to do it in early stage. Django takes away a lot of project infrastructure decisions from developers, offering solid help there (migrations ootb, custom commands infrastructure, separate test configuration, auth and user management, pluggable apps etc) , but requires keeping to specific project architecture.
I browsed through
(And not mentioned with paver):
So most of the commands are already accessible with paver and my instinct would be to add/modify the commands in the docs that aren't covered yet. Or would it be better to drop paver altogether and move to
Some of the paver commands use
IMHO: moving to Django would be an entire different discussion with more sides to it than CLI.
@borrob thanks for looking into this. Bit hard for me to estimate. For new projects I (others) usually start with
We don't have a real (
In the longer term I would like to see a GHC install from PyPi and instance(s) with this scenario, all commands with options/flags as to run in automatic installs like Docker. Each subcommand handles a set of related actions:
But this will be a longer path, we need project-discussion for. In the short term is it an idea to keep Paver for the development and install (e.g. it downloads .zip for JS libs) phase and introduce
As for Django: yes, seen in many Flask-projects, one starts building/adding components to finally get to what Django has built-in or provides in Django-app-extensions: migrations, (registration-) forms, (DB-)views, REST, translations, encrypted passwords, multiple configs etc. My ideal architecture for the future would be a Django-REST app with a
To summarise the discussion and actions:
Short term solution
Long term solution
I can start with the short term items. Where do we document the PSC items? New issues? A wiki page?
@borrob Good summary! Agree you go ahead with Short Term Solution.
GHC does not have a PSC yet, was also a trigger to start one...Also needed for OSGeo.org incubation AFAIK. We can model after