Open aaraney opened 8 months ago
Makes sense! I like either of the first two names. While the repo is entirely python, naming the repo with tools/utils seems the most descriptive.
My mind went to ngen-utils
on its own, so I'd probably go with that (or possibly ngen-py-utils
; see below). It conveys the relationship to ngen
, the general purpose, and the notion of there being several things within. That said, I think I would be fine with the other similar suggestions in the description.
Now, if the powers-that-be also decided to exclusively make this repo a place for Python tools, then adding the py
component to the name might be a good idea; i.e, ngen-py-utils
. Otherwise, I'd try to leave py
out.
Also, fwiw, I'd be worried about just ngen-py
by itself causing confusing, as it kind of suggests a Python implementation of ngen
(in addition to the question of whether non-Python tools will ever be added).
My first thought was ngen-toolbox, but I think ngen-tools and ngen-utils may be better/more concise but just as descriptive. Some other thoughts; ngen-pybox, ngen-pytools, ngen-utilipys, ngen-pyhelpers, ...
I actually kind of like ngen-pybox.
ndk
so we can confuse native development kit
with ngen development kit
🤣
I'm quite ok with scrapping the ngen-cal
name in favor of something very generic, possibly not even ngen
related and maintaining a better description and README to help explain the goings on in the repository.
jobless.celery
was a good candidate from this generator
Some perhaps more apt descriptive names from an AI generator
hydro-hysteria
🤔 flow-follies
ngen-tech
model-mischief
, aka ngen-mischief
ngen-ninjas
water-whackers
Though as I write this, the ngen-dk
repository might be a nice, a simple name implying development kit functionality for ngen
which could host fundamental things like ngen configuration and bmi configuration through to calibration and uses/application of ngen. If it maintains a strong python focus we can use ngen-py-dk
if we want to use some python branding.
Yeah, I like where your mind is wandering @hellkite500. Why not just ngen-dev-kit
?
Why not just ngen-dev-kit?
I'm a lazy typer, and dk
is quite fast to hit the two keystrokes on the same row, compared to dev-kit
which requires keys on all three 🤣
Other than that, no real preference between the two.
I'm leaning toward ngen-tools
.
Consider mine another vote against naming the repository with py
just because the current stuff all happens to be in Python.
My biggest concern with tools
is that it will imply a landing spot for any ngen related "tool", e.g. simple workflow scripts, analysis scripts, ect. We already have to decouple some of these things and re-organize to try to keep clean lines between supporting libraries and "development tools" and "script/analysis tools" which are more on-off and less general.
We can try to hold something of a line against accepting PRs like that into this repo
Revisiting this with some fresh thoughts. Here are a few other options:
hangar
ngen-depot
ngen-room
@aaraney, my immediate reaction to those latest three was, "why?" And I mean that in the purest sense: they seem neither appropriate nor inappropriate at first glance, so I'm curious what was behind those.
My biggest concern with
tools
is that it will imply a landing spot for any ngen related "tool", e.g. simple workflow scripts, analysis scripts, ect.
@hellkite500, that's a valid concern, but I don't think it aligns well with what's happened in practice with the repo. I.e., where exactly is the line for what belongs here versus what doesn't?
If we have to be very nuanced to unambiguously describe that line, we probably can't come up with any suggestive, concise name for the repo that doesn't risk misinterpretation. In which case, we'd either have to accept that risk or adopt a name that does not imply purpose and/or contents of the repo, forcing people to learn those things more deliberately (maybe that's what was behind those last three suggested names?).
Alternatively, it may be appropriate to rethink whether the repo name is right and it is the contents that need to be changed/moved. That's not a small question, but this issue comes up because things that maybe could/should have gone somewhere else were put in this repo. At least relative to it's prior contents at the time, this seems like using the repo in a way much like what Nels was concerned about. And it might be difficult going forward to clearly define rules for what does and doesn't belong if the history of the repo is inconsistent with the general principles behind how we'd want to distinguish things now.
@aaraney, my immediate reaction to those latest three was, "why?" And I mean that in the purest sense: they seem neither appropriate nor inappropriate at first glance, so I'm curious what was behind those.
Just trying to come up with names that were a bit more fun and included a play-on-words. Im certainly open to something like that.
For better or worse, this repository has become the landing space for many NextGen related tools. Namely, tools for calibration, realization configuration, init config representation, and configuration generation. I like that this repo is operating as monorepo for a lot of our tooling around NextGen. It is so far, easy to maintain and once you've found it, you've found the majority of tooling around NextGen. However
ngen-cal
is no longer an appropriate name. For our sake and more so, the communities sake, I think we should adopt a new repo name sooner rather than later. A different name that better encapsulates the tools in this repo will help others discover these tools and hopefully drive usage of these tools.To start the discussion, below are a few suggestions. Please think about this carefully and add others that come to mind before reading my suggestions.
ngen-tools
ngen-utils
ngen-py
ngen-tooling