Patch for Windows Users

[SherylHohman]

Conda v 4.2 and up changed a default settings which causes install problems on many Windows machines. PaddingError

This file restores the default setting of prior releases, to allow for proper install of many packages to windows.

This file is automatically run first in the build process, in order to allow for customized environment settings.

This file is ideally specifically to be run on Windows machines only (I dunno how to have the OS read automatically, and only apply it to Windows machines). Since it used to be the default setting, it might be fine to run it on linux or macos as well.. However...

Perhaps it's better to name the file something like meta-windows_patch.yml, and have windows owners rename the file appropriately so that it gets run (but ignored otherwise)

[SherylHohman]

Here are the threads that helped me out, and also explain what the issue is:

Conda Docs info on ignore-prefix-files

Conda Docs Info about a related [detect-binary-files-with-prefix](http://conda.pydata.org/docs/building/meta-yaml.html#detect-binary-files-with-prefix) flag that helps explain the one we are setting

BountySource thread about this issue

known issue causing conda install (or package installs) to fail with PaddingError on windows machines

conda-forge github thread reguarding this known issue

meta.yml file is used to set the flag
http://conda.pydata.org/docs/building/recipe.html

Continuum.io thread on downgrading to conda 4.1 until it gets fixed

how to downgrade to conda 4.1 if the meta.yml file doesn't do the trick, this should

StackOverflow thread confirming issue, and offering another alternative: shorten the URL path to your files if possible

[domluna]

Hi @SherylHohman, thanks for putting this together. I'm a little confused how this is used with environment.yml. Does it detect it automatically or does something else have to be done? Also I think http://conda.pydata.org/docs/building/meta-yaml.html#preprocessing-selectors could be used to make sure this only runs for Windows.

What package is giving these issues? I haven't encountered this on Windows 10.

[SherylHohman]

It may also be required to downgrade to conda 4.1, if the original anaconda installation had any PaddingError issues with any of the packages..

https://carnd.slack.com/archives/setup/p1485215163000693?thread_ts=1485206083.000674&cid=C39QJ3883

[SherylHohman]

@domluna

It won't cause an issue on every windows machine. But the issue can show up during the install of any particular package, depending on how the package was written. For me matplotlib, an a few others would not install properly.

Yes, the meta.yml file is automatically run first, and is used to set build variables before running the other files. This used to be the default setting before conda 4.2. Conda does not use the variable correctly on windows machines.

Here is an excerpt from an above mentioned BountySource thread

... The whole padding error stuff is pretty meaningless on Windows, since it has a hard path limit of 260 characters (that is going away soon?).

That error came up because it tried to do the traditional prefix replacement, which it really should not be doing. They pip entry point replacement doesn't care about length - it just splits up the binary, replaces the prefix, and makes a new sandwich. ... Yeah, exactly. I'm not sure I'd ever call it inappropriate. It is information that should be correct, but how it gets interpreted and acted upon is the thing that makes it inappropriate. If the information is flat out wrong, like conda-build is making stuff up, then I'd call conda-build's behavior inappropriate.

Conda-build is the only reliable source of knowledge about the prefix, because only it knows what the prefix was at build time. That's the only reason it is involved here. Really, conda is doing all the magic (and any unwanted hijinx) here. ... Right, sorry for the inactivity - we've been using ignore_prefix_files where this was a problem. ...

The conda docs also mention something about this, which I linked to in comment2. I linked to a few other discussions there as well.

Conda below 4.2 does not suffer from this issue.

It could be related to path lengths, which it should be ignoring in windows, and also be why random people are experiencing this on random packages.

Also it is dependant on the length of "placeholders" that some developers for some packages use. Another reason why it affects Some packages, and Some windows installs.

Here is PR on conda github and thread on Continuum's forum (anaconda and miniconda), which restates the issue, and suggests a downgrade to conda 4.1 (where the variable I have set in the meta.yml file, already uses that default, so it doesn't need to be overridden) - essentially both methods set the ignore_prefix_files variable to True. and another Stackoverflow comment by conda contributor

The other work around has been to downgrade to use conda 4.1.

I actually downgraded to 4.1, then deleted my carnd-term1, recreating it with the meta.yml file added. The combo of both worked for me. Don't know if just the downgrade plus recreating carnd-term1 after that would have fixed the problem, or if recreating the carnd-term1 with the meta.yml file (but no downgrade) would also have worked. It's just by chance that I wound up doing both before the recreation of carnd-term1.

[SherylHohman]

Yes, some method of reading the OS to decide whether or not to run the meta.yml file would be best. (it also might be necessary do downgrade to 4.1.1).

As stated, I don't know how to do that, but if given a hint, I'd be more than happy to figure it out, and add it to the PR.

[SherylHohman]

I have uninstalled conda and reinstalled anaconda (uses conda 4.2) then recreated carnd-term1 using the meta.yml file as indicated. CarND-Term1-Starter-Kit-Test works PERFECT.

So, I've confirmed that downgrading is not necessary if you use the meta.yml file when creating the carnd-term1 environment.

Not every windows user will experience this issue,
but is is one that any windows user Could experience, depending on their system, file paths, and a certain "placeholder" lengths in various packages.
Hence, when/if install issues occur can appear to be slightly random. It can happen for any additional package install or update. It is an issue with the way conda is applying that setting on windows machines (it is incorrect).
It is a pre-emptive move that prevents this issue from occurring.
It won't harm windows users that don't run into the problem. And it used to be the default.
This simply prevents conda from doing something that it should not be doing, as it handles the new default incorrectly when it tries to apply it to windows machines.
Windows machines do not need the code that this flag (at the new default) is set to execute.
Windows machines are in some way exempt from needing this check.
And when the check is performed, it interprets the result incorrectly, and causes code failure, sometimes, on windows.

This is my understanding from reading the above mentioned threads, and more. I never even heard of conda before a couple days ago, so you might get a more solid, and slightly more accurate interpretation from the above posts than I, but I'm pretty sure I got the gist of it right.