Tony Kelman

I'd rather not, personally. Aside from notepad.exe, what programs can't handle unix line endings by now? If you really want `\r\n`, you can `run(`unix2dos out.txt`)`

Even if the code that's currently in base is going to be improved, there's not much reason for it to remain in this repository and coupled to the release schedule...

sorry my mistake, nevermind that comment. but note that the julia code here is very old and almost entirely replaced elsewhere, e.g. StatsFuns.jl

that may make sense

I like the sound of that because, and correct me if I'm wrong, packages could also plug into this approach without having to special-case certain types in base, right? So...

xref https://github.com/conda-forge/conda-build-feedstock/pull/251 and https://github.com/conda-forge/conda-forge.github.io/issues/2491 and https://github.com/lief-project/LIEF/issues/1170, looks like lief upstream has fixed this in 0.16.4

The test output changes from https://github.com/aws/aws-cli/pull/8072/commits/1b5ef38e2e36d760fd3ebe98811fb606ecc996df (and raising the version floor accordingly) probably need to be pulled in here

Has anyone gone to the lengths of building and testing against a pre-release dev version of LIEF? That would be one way of getting a head-start in seeing for sure...

https://github.com/conda-forge/conda-build-feedstock/pull/263 is a really good start to this. Chime in if anyone disagrees but I think these are the next areas of work, now that there's a `lief_dev` label for...

If we really need an ascii infix not-in operator (is `!(a in b)` not sufficient for most purposes?) then I'd rather have it spelled `notin` than `ni`.