no-arch packages are breaking downstream

[jreback]

looks like #18 is now creating no-arch packages, which I don't think works. recipe needs to revert 'numpy x.x'

xref pandas-dev/pandas#17757

                            3.4.2               np112py27_1  conda-forge     
                             3.4.2               np112py35_1  conda-forge     
                             3.4.2               np112py36_1  conda-forge     
                             3.4.2               np113py27_1  conda-forge     
                             3.4.2               np113py35_1  conda-forge     
                             3.4.2               np113py36_1  conda-forge     
                             3.4.2                    py27_2  conda-forge     
                             3.4.2                    py35_2  conda-forge     
                             3.4.2                    py36_2  conda-forge     

[ocefpaf]

That is not noarch, it is the same strategy used for wheels where we build with an old "enough" numpy and then run with the latest version that is backwards compatible.

I'll check the errors and see if this is the cause but I suspect it may be something else.

[isuruf]

This might be the error, aac7372
cc @dougalsutherland

[ocefpaf]

@isuruf what if we do a build lzo 2.06 and run lzo >=2.06,<2.11?

https://abi-laboratory.pro/tracker/timeline/lzo/

[isuruf]

I don't think that matters. Earlier lzo 2.06 was coming from defaults and that may be compiled differently to the conda-forge package.

[ocefpaf]

I don't think that matters. Earlier lzo 2.06 was coming from defaults and that may be compiled differently to the conda-forge package.

What do you suggest? >=2.09 ?

[isuruf]

Figure out what the difference between defaults and conda-forge is, or why 2.06 was needed in the first place.

[ocefpaf]

Figure out what the difference between defaults and conda-forge is, or why 2.06 was needed in the first place.

Hard to know. It is one of the old style packages without a recipe or useful metadata.

[djsutherland]

Sorry about this. I don't see any useful debug info in the Travis log, though (just Slave crashed) – am I missing something?

Installing the build from the broken label I'm able to import tables, and can do DataFrame.to_hdf(..., compression='lzo') and then pd.read_hdf it back in successfully (on Linux). Without any further error messages it's pretty hard to debug any further....

[djsutherland]

Also lzo is supposed to be 100% ABI backwards-compatible from 2.01 on, so I don't see how #20 would have changed anything.

[ocefpaf]

@dougalsutherland it is really hard to debug things like this. The package is functional and some bad interactions with the pandas dependencies are probably the issue here. So no need to be sorry, the changes you submitted were 100% valid!

With that said, the "broken" label is temporary until @jreback gives us feedback on the pining in my test PR. If that reveals the same issue then we need to figure something out, maybe even reverting to 2.06 😒

Also lzo is supposed to be 100% ABI backwards-compatible from 2.01 on, so I don't see how #20 would have changed anything.

#20 forces conda-forge lzo only b/c we did not build 2.06.

[ocefpaf]

Pinning to lzo 2.06 did not work 😕

https://travis-ci.org/ocefpaf/pandas/jobs/282908001

I'll make more experiments to see if we can isolate this. If the numpy builds are really the culprit I believe we may have found a bug in numpy somewhere... Not sure.

[isuruf]

Another issue might be a594aaa

[ocefpaf]

Ah yes! The zlib may be the culprit here. Let https://travis-ci.org/ocefpaf/pandas/jobs/282908001 finishes and I'll try that.

[jreback]

confirm pinning lzo=2.06 doesn't change things: https://travis-ci.org/pandas-dev/pandas/jobs/283125250

[ocefpaf]

I've been doing some testing and nothing so far. I haven't test zlib yet, getting there...