Handy utilities = Friday Filosofical Finking

[Chris Angelico]

On Tue, Apr 2, 2019 at 1:21 PM DL Neil <PythonList at danceswithmice.info> wrote:
> > Sometimes, I recollect and reference, which creates some very weird
> > interdependencies until I get around to refactoring...
>
> but some fairly hairy "technical debt" meantime?
>
>
> > https://github.com/Rosuav/MegaClip/blob/master/deviquotes.py
> > imports https://github.com/Rosuav/shed/blob/master/emotify.py
> > which gets an API key from the non-sample version of
> > https://github.com/Rosuav/MustardMine/blob/master/config_sample.py
> > and the end result of deviquotes is to rebuild this
> > https://github.com/DeviCatOutlet/devicatoutlet.github.io/blob/master/quotes.md
>
> The twists and turns are positively admirable, but promoting the above
> as a training exemplar might not be the best idea!

Oh, I *never* said this was best practise! Let me be clear here: This
is NOT an organizational structure. It is a lack-of-organization
structure.

> Back to the original question(s): something I didn't want to do was to
> have a hard-coding of the import sourceDIR (per above). Whilst the
> PYTHONPATH is (at the very least) a form of "hard coding", at least I
> can do that to/on a client's m/c separately/in-addition to loading the
> s/w AND know that the Python code 'there' is the same as I have (in
> repo) 'here'!

This actually isn't so bad though. The paths are deliberately
relative, and the only requirement is: If you want these projects to
interoperate, clone them into the same parent directory. So you can
have a "projects" directory, or drop them all into your home
directory, or stick 'em into a "stuff that's trying to work together"
directory, or anything like that, just as long as they're peers off
the same parent.

> > So running that one script can potentially involve four different
> > repositories, because I haven't yet made any of the pieces into proper
> > libraries...
>
> - and if I did the same, would you pay me (as much) for delivering such?
> (different rules for personal stuff)

This is personal, so the "different rules" are the ones that apply.

For commercial software that's expected to be able to run on arbitrary
people's machines, tidying this sort of thing up would be a
pre-deployment priority. But then the question would be: which part of
this is being sold? Mustard Mine stands alone (the others call on it),
so it can viably be distributed - and in fact, is designed to be. None
of the others really need to be, so it's hard to answer in theory.

But you're absolutely right that this is the sort of thing that makes
it hard to sell a piece of software. Gotta have clean distribution.

ChrisA