Toby Bellwood

Thanks, I got there in the end. It's more of an issue that it's very undocumented that this is how it works, and although the pwd is mounted in the...

yup - that's where we got to - as blacklisting *after* resolution removes the entire package - the blacklist should happen *during* resolution for the safe version to be included!

the issue there is that it becomes a composer anti-pattern. The blacklist issue raises it's head worst with child dependencies (which aren't defined in the root composer.json), or cross-dependency mismatches...

Am I correct in reading this issue like so (and from our experimentation today)? From https://www.drush.org/12.x/using-drush-configuration/#directories-and-discovery Any alias-path config will only be read from 3 (--config), 4 (~/.drush/drush.yml) or 5...

we've already got the wildcard aliases - which work ok, but we're implementing a per-cluster ssh endpoint, which means that the wildcard might not always work, so for certain cases...

How can we dynamically tell drush to read from an alias file we create, if we can't control the drush command - assuming there is also a hook to read...

Hmm, will have to consider how much we can set any of these hardcoded files, switches or paths dynamically, hence the preference for using the drush internals. On a site-by-site...

I would also recommend publishing to dockerhub (for discoverability) but applying for DSOS status to get rate limiting and retentions lifted - https://www.docker.com/community/open-source/application/

> And why use Debian "by default", when other distributions are clearly suitable? My 2c (as large-scale consumers of images ourselves and a re-packager of upstream images for our downstream...

More additions from Australia: https://www.dta.gov.au/standard/7-open-standards-and-common-platforms/ https://www.dta.gov.au/standard/8-make-source-code-open/