Try uploading with latest version

[jakirkham]

Would be good if we could try using the anaconda-client we built to upload itself. This way if it is incompatible with the standard feedstock upload process (currently the upload script), the CI will error and the package won't be published. This should catch errors before breaking other feedstocks in the process.

[jakirkham]

Have submitted PR ( conda-forge/conda-smithy#718 ) to just this in conda-smithy. Also included in commit ( 071bfb6 ).

[jakirkham]

Note this should help us catch problems like issue ( anaconda/anaconda-client#463 ) earlier in the future.

[isuruf]

Is the new version working? https://travis-ci.org/conda-forge/sagemath-db-polytopes-feedstock

[jakirkham]

I’m not seeing an error. Where is it?

[isuruf]

See https://travis-ci.org/conda-forge/pari-feedstock/jobs/353485424 and other recent builds. I moved anaconda-client recent build to hold for now

[jakirkham]

Thanks @isuruf. The report is surprising actually.

Had added PR ( conda-forge/conda-forge-build-setup-feedstock#94 ) to switch to the new API (it is actually quite old, but preferred and will soon be the only API) and it passed with the existing anaconda-client); hence, it was able to upload. Then merged the anaconda-client update here only after conda-forge-build-setup was built and deployed. Also as previously noted had added commit ( 071bfb6 ) to use the newly built anaconda-client to upload itself, which went through ok. So this feedstock already actively tested the new anaconda-client is compatible with the updated conda-forge-build-setup. IOW it worked in this case, not sure why it failed in other cases.

The log indicates that the upload script is using the old API to do the upload. The recent build of anaconda-client had the new and old APIs as we added the old API back in PR ( anaconda/anaconda-client#467 ), which this release includes. So both APIs should work and be supported. The backcompat function (old API) is identical to the in 1.6.5, which is what we were using before as that is where I had pulled it from. Further with the updated conda-forge-build-setup, the new API should be used instead. IOW not sure why the old API wouldn't work here or in fact why the old API is being used at all. 😕

The cls variable it is complaining about we don't actually set. So it is whatever the default is (as it has been even when using the old API). Not sure why it is being set to an int object in the end or why an int object would be used as a callable. This gets deeper into the guts of anaconda-client and so am not really sure what is happening. Maybe @abarto will have more insight.

In any event, if either the new anaconda-client or the updated conda-forge-build-setup is causing problems am more than happy for you to pull either as needed. Though we should try to isolate the issue and understand the cause. Using an anaconda-client that is quickly falling behind on patch releases is not a good place for us to be. Did pulling anaconda-client solve the issue? Was this happening in every feedstock or only a few? Did restarting affect the result (IOW is the error sporadic or consistent?)?

[isuruf]

Did pulling anaconda-client solve the issue?

Yes

Was this happening in every feedstock or only a few?

All of the feedstocks I saw

Did restarting affect the result (IOW is the error sporadic or consistent?)?

No, it didn't

[jakirkham]

Guessing all of the errors were the same?

[isuruf]

Yes. all of the errors were the same

[jakirkham]

Was this in all CIs or only some of them?

[isuruf]

It was only Travis-CI, but I don't think there were any Circle-CI or appveyor jobs running during that time

[isuruf]

There were appveyor jobs, but they didn't fail

[jakirkham]

Knowing that this also passed on CircleCI and given what you have already said, this sounds like a Travis CI specific issue. That's good to know. Thanks for the extra info.

[jakirkham]

Wondering if this was an issue of lag? Not really sure why that would matter, but I could be missing something.

[isuruf]

It could be that newer version conda-forge-build-setup of was not uploaded because of the lag in travis-ci.

[jakirkham]

That's what I'm wondering. Though again can't think why that should matter.

We could test this to be sure. Doesn't have to be now though. Would have to be when Travis CI is not heavily queued up though.

[jakirkham]

Have moved anaconda-client back into main and retested with a Travis CI build and it uploaded fine. So think this was just a stale conda-forge-build-setup getting pulled in by some builds. We should keep an eye on this. However if it isn't causing problems, would like to keep the new anaconda-client in main.

[jakirkham]

We could convert this back to an arch specific package to catch these sorts of issues in the future before a new anaconda-client gets published and interacts poorly with our infrastructure for whatever reason.

[mariusvniekerk]

There is a small issue in the current version of anaconda-client
anaconda/anaconda-client#468

Can we mark v1.6.13 as broken. Seems to cause weird issues with conda env amongst others

[abarto]

I'll fix it right away.

[abarto]

I've tagged 1.6.14 and ask the distribution team to push the release onto the public channels.

[jakirkham]

Thanks for looking into that @mariusvniekerk.

That said, we should no longer be using get_binstar. We call get_server_api directly.

Are you seeing issues in conda-forge related to this?

[mariusvniekerk]

yeah basically the existence of that method broke usage of things like conda env, so nothing really conda-forge related

[jakirkham]

Ouch! Do you have any examples? Would like to be able to identify the issue should it crop up again.

In any event, 1.6.14 is now out, which hopefully alleviates this issue. Please let us know how it goes.