“ofx” is a pretty non-descriptive name. It also clashes with the convention that the ofx prefix indicates that something is an OF addon. Maybe change it to something slightly more verbose, like OFAddonManager or somesuch.
Placing it in the OF root directory will make it clash with the OF git directory contents, and show up as additional content. Also, I think it’s not a fitting place for a tool external to OF. A better place would be outside the OF repo (preferred), or _maybe_ in /apps/myApps/. Also, keep in mind that some people keep several different copies of OF around - it would then be unnecessarily necessary to also have several copies of your tool.
It might be best to pre-configure a string with the path to the addons directory - I know some people store their addons outside of OF/addons
Do you know the excellent argparse python module for parsing command line arguments? generates automatic help etc, pretty awesome. for an example on how you can use it, see https://github.com/bilderbuchi/ofStateManager (which is a similar service tool for OF workflows)
In places like https://github.com/prusnak/ofx/blob/master/ofx#L184, if you construct your paths with os.path.sep, os.path.join(), you are further along the road to cross-platform compatibility. yeah I know the ‘cd’ will fail on windows nevertheless, but the point still stands.
I moved this to the more appropriate “extend” subforum.
I quite like the idea of having a tool called “ofx” that maintains addons that start with the prefix “ofx”. The clash argument is IMHO weak, because you can easily tell if the string describes a plugin (there are some characters after the “ofx”, which is just the prefix) or the tool (it’s just the “ofx”, no chars after that).
Introduced OF_ROOT and OF_ADDONS environment variables that can override the default settings ‘.’ and ‘./addons’.
Yes I know them. Unfortunately, argparse/optparse modules are not helping a lot with syntax I decided to use (one keyword (no minus blah) and one parameter).
Fixed the os.path.join part. Git calls could use some love of course …
Well, let’s agree to disagree, then. I think it makes more sense if it’s immediately obvious from the name what a tool does. of course, there are examples for both sides (pdftops vs. tar for example). Also, I wonder what will happen if we (hypothetically) get another app which does something different with addons, and the dev also calls it “ofx” (following your chain of reasoning)
I’d like you to try searching for your repo on github, though - put “ofx” into the search bar on top. apart from the face that there is already another repo called ofx which has nothing to do with OF, your repo is swamped by all the addons, and appears somewhere on the fifth page of search results for me.
thanks, that ameliorates the problem.
yes it does, I use the same subcommand syntax (with a more extensive option tree), have you looked at my code?
what I liked most is that I don’t have to do any parsing, help is autogenerated nearly, and it’s much easier to catch input errors - e.g. what happens if you type “ofx list category MyCategory” (obviously wrong, but your parser doesn’t check for number of args). But hey, I’m not trying to push you or something.
I did check the example but it was not entirely obvious you are subcommand syntax. I might look into that again, but currently it’s low priority. If you send me a patch, I will review and include it, though.