Document missing support for binary prefix on Windows

[msarahan]

@dolfim commented on Fri Jan 06 2017

I think the documentation should state more clearly that binary prefix replacement is not fully supported on Windows.

The only comment about it that I could find is in the conda sources:

# on Windows for binary files, we currently only replace a pyzzer-type entry point
#   we skip all other prefix replacement

https://github.com/conda/conda/blob/master/conda/core/portability.py#L87

---

@msarahan commented on Fri Jan 06 2017

I'm not clear on why this needs to be documented. Binary prefixes only affect Linux and Mac as far as we've been able to see. They actually break lots of stuff on Windows because of Windows' 260 character path limit (which has been very recently removed, but still needs to be respected for quite a while.)

---

@dolfim commented on Fri Jan 06 2017

My point is that the docs does not state clearly that prefix replacement in binary is supported only on Mac and Linux. It explains how this is done on those systems, but after reading a few times I was still sure that some other black magic was implemented for Windows.

---

@msarahan commented on Fri Jan 06 2017

OK, fair enough. I'll move this issue to the docs repo and try to fix it soon.

[benmwebb]

+1 from me (was just about to open an issue on this). This has caused us a lot of grief recently since our Windows packages randomly stopped working. Turned out to be because we built them just after conda/conda#3262 got merged (which added binary prefix support on Windows) but our users tried to use them after conda/conda@4764dff51b (which removed it again). Our software is cross platform but has a Unix heritage, so it relied on binary prefix replacement.

We finally gave up and avoided binary prefixes on our Windows builds, but we would have saved a lot of time if the documentation mentioned that the replacement didn't work on Windows (better yet, have conda build warn or error out if meta.yaml has detect_binary_files_with_prefix: True on Windows).

[msarahan]

fixed in https://github.com/conda/conda-docs/pull/389/commits/7978f80df7bc6ac974d3d5f0725851fdd8d31044 - please review and let us know if that is adequately clear.

[benmwebb]

Looks good to me (although we don't use hardcoded embedded paths for locating other dynamic libraries; we use them to find the program's data files, which on Unix systems would typically live in /usr/share/).

[dolfim]

Good to me. Also for us the problem is actually the dynamic loading of data files. The solution in this case was to make use of the (already existing) environment variable that I set automatically with a file in the activate.d folder. But still the binary contains the build path which is a pity.

[benmwebb]

For the sake of completeness, our solution was to use GetModuleHandleEx and GetModuleFileName to get the full path to a DLL in our software, and then use that to construct a path to our data file (since the relative path between the two is fixed). We patch the source code this way via meta.yaml only for Anaconda Windows builds (could also remove the build path at the same time).

[rrigdon]

https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#build-section

[github-actions[bot]]

Hi there, thank you for your contribution!

This issue has been automatically locked because it has not had recent activity after being closed.

Please open a new issue if needed.

Thanks!