You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To expand on the title some more, I'm wondering what direction to take this going forward.
My personal goal is to make this as easy as possible to install and use. This means removing the docker image needed to build dependencies from source and eventually make it as easy as pip install ngiab_data_prep with pypi CICD.
This isn't technically tricky to do, but the more the inner workings are abstracted, the more this moves away from being a python notebook/module designed to be forked and modified.
Open questions
Is this going to become primarily a desktop tool?
How important is it to keep features simple and minimal to keep the code easy to fork and make modifications to?
Should this move to a pip tool? something like snakeviz where you pip install it and run it without ever cloning a repo.
Based on the answers to those questions
If it's going to be a desktop tool should we move to kivy/qt/tkinter to create a proper desktop application?
Possibly port to a QGIS module?
Should we separate the data-processing + cli and the front-end?
How do we decide what features to add and their priority?
Initial thoughts
Ultimately it's up the the users who get value from this tool and I'm not going to pretend to know what a good direction for this is. I'm a proponent of simplicity, perhaps overly so, and I like the unix philosophy:
Write programs that do one thing and do it well.
This goes outside the bounds of one thing as it is a frontend, subsetter, forcings engine, and configuration-generator all in one, but there's value in the ease of installing one tool that does all the ngiab data preprocessing rather than chaining 4 together.
However, the more this expands, the trickier it becomes to comprehend and modify for personalised use-cases. Additionally it will overlap more with existing tools like DMOD and others that may be better suited / already capable of handling a richer feature set.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
GUI first or code first?
To expand on the title some more, I'm wondering what direction to take this going forward.
My personal goal is to make this as easy as possible to install and use. This means removing the docker image needed to build dependencies from source and eventually make it as easy as
pip install ngiab_data_prep
with pypi CICD.This isn't technically tricky to do, but the more the inner workings are abstracted, the more this moves away from being a python notebook/module designed to be forked and modified.
Open questions
Based on the answers to those questions
Initial thoughts
Ultimately it's up the the users who get value from this tool and I'm not going to pretend to know what a good direction for this is. I'm a proponent of simplicity, perhaps overly so, and I like the unix philosophy:
This goes outside the bounds of one thing as it is a frontend, subsetter, forcings engine, and configuration-generator all in one, but there's value in the ease of installing one tool that does all the ngiab data preprocessing rather than chaining 4 together.
However, the more this expands, the trickier it becomes to comprehend and modify for personalised use-cases. Additionally it will overlap more with existing tools like DMOD and others that may be better suited / already capable of handling a richer feature set.
Beta Was this translation helpful? Give feedback.
All reactions