omnia-md / conda-recipes

conda build recipes for the Omnia project
http://omnia.md
MIT License
24 stars 37 forks source link

Need to rebuild swig #675

Open jlmaccal opened 7 years ago

jlmaccal commented 7 years ago

I get the following error when trying to build MELD:

conda.CondaMultiError: Placeholder of length '80' too short in package /anaconda/conda-bld/master_1484775469603/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho/bin/swig.
The package must be rebuilt with conda-build > 2.0.

Swig is pulled in from the omnia channel.

@jchodera @Lnaden: Can we bump the build number of swig to force a rebuild?

Incidentally, why are we packaging our own version of swig anyway? Isn't included as part of anaconda?

jchodera commented 7 years ago

@Lnaden: Can you bump the swig build number?

@jlmaccal: I'm not sure swig was always available---swig 3.0.8 was only uploaded 11 months ago, and 3.0.7 (which was used to build OpenMM 7.0.1) isn't available at all via conda.

Lnaden commented 7 years ago

Yes.

I am trying to actually replicate this issue locally so we can proactively find these instead of reactively.

jlmaccal commented 7 years ago

OK...

I was building against 3.0.7, which was likely built with conda < 2.0.

I've unpinned the version of swig used in MELD, which should pull in the latest version of swig, presumably built with conda 2.0.1 or later.

It occurs to me that one weakness of the current system is that changes to the build tooling (meta.yaml, docker_build.sh, et al) don't actually trigger a rebuild of the packages.

jchodera commented 7 years ago

I am trying to actually replicate this issue locally so we can proactively find these instead of reactively.

I think the cascade of nightli.es will clue us in to any other issues like this over the next couple of days.

jchodera commented 7 years ago

It occurs to me that one weakness of the current system is that changes to the build tooling (meta.yaml, docker_build.sh, et al) don't actually trigger a rebuild of the packages.

They shouldn't. And they shouldn't need to. It's total bullshit for continuum to break backward-compatibility like this.

jchodera commented 7 years ago

If we really need to, we could use the --force flag once to force a rebuild of all packages, but it may not make it through all of them, and they would all have the same build number.

Let's try to be conservative and only rebuild the ones that need it by incrementing the build numbers.

Lnaden commented 7 years ago

I made a PR for this by unpinning meld.

I'll keep trying to replicate locally to find a proactive way to test. The problem with letting nightli.es fix it is that these builds crash when even 1 package fails, so we would only catch them at a rate of 1/day unless someone chimes in on the issue tracker.

jlmaccal commented 7 years ago

It's total bullshit for continuum to break backward-compatibility like this.

Agreed...

Just to be clear... I think in hindsight my issue doesn't require rebuilding swig. I was just using the previous version using an incompatible version of conda-build.

jchodera commented 7 years ago

Just to be clear... I think in hindsight my issue doesn't require rebuilding swig. I was just using the previous version using an incompatible version of conda-build.

Can you clarify?

jlmaccal commented 7 years ago

Sorry for the confusion...

The error was not due to the recent update of conda in the last few days. It was due to a previous update to conda 2.0, which happened in September.

The swig version for the meld openmm plugin was pinned at 3.0.7. This version of swig was built with an old version of conda-build. I have since unpinned the version of swig, so it now grabs 3.0.8, which was built with conda-build 2.0.1 and works fine.