On Tue, Apr 2, 2019 at 1:21 PM DL Neil <pythonl...@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 -- https://mail.python.org/mailman/listinfo/python-list