Packages require rebuilding with conda-build > 2.0

[jakirkham]

From @lparsons on February 23, 2017 22:51

I've run into an issues with a couple of packages (from the r channel) which give me the error:

PaddingError: Placeholder of length '80' too short in package [channel]::[package]
The package must be rebuilt with conda-build > 2.0.

While these are coming from the r channel, I believe this is the new home for these packages? Or at least could be?

The packages are:

• r::r-base-3.2.1-0
• r::r-base-3.2.2-0

Copied from original issue: conda-forge/r-base-feedstock#12

[jakirkham]

So if they were our R packages (no pun intended), they would be called conda-forge::r-base.... As this is not the case and as r is an Anaconda maintained channel, I'll refer you to Anaconda's recipe issue tracker. Hopefully that will get you closer to someone that can help.

[jakirkham]

Raising to your attention, @mingwandroid. Hope this is an ok place to put this issue. 😁

[mingwandroid]

Thanks. @lparsons, I'm not planning to rebuild these old r-base packages with conda-build > 2.0. We are now on r-base 3.3.2. Is there a reason that you care about these old versions?

[lparsons]

Thanks for looking at this. For reproducibility reasons, Galaxy tools pin versions of dependencies.

[mingwandroid]

If you are now trying to use conda-build >=2.0 on a package that was previously built with conda-build < 2.0 then you are very far from reproducible I am afraid.

[lparsons]

Sorry, I'm not very familiar with the intricacies of conda builds. Are you saying R 3.2.1 doesn't behave the same when built with conda-build < 2.0 and R 3.2.1 built with conda-build > 2.0? That just doesn't make sense. Certainly, compatibility with specific versions of packages will be the same?

[mingwandroid]

I'm not sure about making sense here, I guess that's a function of both of us and I guess this comes down to how strict you are in your definition of reproducible. I'd like to be as strict as https://reproducible-builds.org's definition, but we're not near that (yet).

If you had pinned your version of conda-build too then your builds would be more similar (but they may not be installable or useful in a more contemporary conda or with other packages built with a more contemporary conda-build.

A binary built to contain filepaths with 80 characters in it is quite different from one with filepaths with 255 characters.

If you are asking will it function similarly, the best I can offer is 'hopefully'. Programs have bugs, bugs are quite chaotic sometimes and changes in something seemingly as harmless as memory layout / padding can cause latent bugs to become apparent.

As to your actual issue, if you really need to use those old versions of R with more recent packages, you'll need to build them yourself. It's not easy but I'll help where I can.

[lparsons]

Ah, OK. I see where you're coming from. I think the issue we're having is that we'd like to be able to use specific versions of R, but the 80 character path limit causes serious practical problems for many installations. So, an imperfect, but still good workaround would be to rebuild these packages.

[mingwandroid]

Can you show the exact command / recipe / environment file that causes you to get this? I don't think there'll be much I can do but I am curious.

[lparsons]

I'd have to dig through some logs, be t essentially it's creating a conda environment in a "long" path. At least, that's my understanding of the issue. Perhaps @mvdbeek or @bgruening can shed more light.

[mingwandroid]

The problem is usually when mixing packages with long prefixes (new) and ones with short prefixes (old) at conda-build time, but yes, also just trying to install to a long prefix would trigger it.

If you are in control of the prefix, you may be able to use something like /tmp/r as your root?

[lparsons]

No, it's not really realistic to expect the prefixes will always be short. These are being managed by another system, an various installations will almost certainly hit the path length limit.