Test release

[jamesmkrieger]

Comment:

Hi @simonbray

We are almost ready to release v2.5.0, but we’d like to try some things first, about how to include some precompiled fortran-derived C++ extensions as .so files (which we have for python 3.8, 3.9 and 3.10).

Is it possible to send release candidates to conda-forge?

Many thanks James

[jamesmkrieger]

I guess the question is really whether I can trigger release candidate builds from a branch that isn’t on the main prody repo but on my fork and hasn’t been merged yet

[jamesmkrieger]

Would we just change the url and sha256 in the recipe? I suppose the url could point to a tar.gz source distribution from a release made on GitHub using that branch with a tag like v2.5.0rc1

[jamesmkrieger]

It looks like I can also get a new release by merging a pull request as I saw by merging the one for v2.4.1, so I guess this should be the way to try and see

[simonbray]

Hi @jamesmkrieger, sorry not to reply sooner. I don't use conda any more for work.

I don't think what you suggest is the right approach as it will publish unwanted and potentially broken package versions. It should be possible to download the artifacts built by the conda-forge CI from the PR to test them locally. Unfortunately I couldn't find any good documentation, this was the closest: https://conda-forge.org/docs/maintainer/updating_pkgs/#downloading-prebuilt-packages-from-ci.

Another alternative could be building locally: https://conda-forge.org/docs/maintainer/updating_pkgs/#testing-changes-locally

Perhaps you can have a look around and ask for help in the conda-forge gitter channel if necessary?

[jamesmkrieger]

Thank you. That makes sense.

Do you know of someone else that works with conda and can help instead?

[simonbray]

No, but you can post on the Gitter channel and someone will give you a hand: https://conda-forge.org/community/getting-in-touch/

[jamesmkrieger]

ok, thank you