Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't try to install conda-forge xcube in AppVeyor build #50

Closed
pont-us opened this issue Apr 28, 2021 · 3 comments · Fixed by #51
Closed

Don't try to install conda-forge xcube in AppVeyor build #50

pont-us opened this issue Apr 28, 2021 · 3 comments · Fixed by #51
Labels
ci related to continuous integration or deployment

Comments

@pont-us
Copy link
Member

pont-us commented Apr 28, 2021

Co-ordinated releases between xcube and xcube-cds (and other plugins) are complicated by the versioning: xcube-cds 0.x typically depends on xcube 0.x, but specifying xcube >= 0.x in the environment.yml breaks the build until the xcube 0.x conda-forge package becomes available -- meaning that xcube 0.x has to be both released and conda-packaged before xcube-cds 0.x can be tested.

The xcube-cds AppVeyor config already goes part of the way to resolving this problem: it actually installs xcube from the head of the master branch. However, before doing this, it also installs its own environment -- which includes the latest (and possibly as yet non-existent) xcube version -- then removes the conda-installed xcube. It would make more sense to do the following:

  1. Clone the xcube repository, create an xcube conda environment (containing xcube's dependencies but not xcube itself), and install xcube directly from the repository.
  2. Create a modified xcube-cds environment.yml which doesn't contain xcube as a dependency.
  3. Update the xcube environment using this modified environment.yml.
  4. Install xcube-cds from the repository.

This ensures that all xcube-cds's transitive dependencies through xcube are satisfied but avoids trying to install xcube itself through conda.

@pont-us
Copy link
Member Author

pont-us commented Apr 28, 2021

It would be good to implement Issue #43 before fixing this one, in order to decrease the AppVeyor build time -- CI config modifications usually require at least a few debugging cycles, so a quicker CI build will save time when fixing the present issue.

@pont-us pont-us added the ci related to continuous integration or deployment label Apr 28, 2021
@TonioF
Copy link
Contributor

TonioF commented Apr 29, 2021

Another idea would be to come back to the use of maintenance and master branches. Changes that are incompatible with the last released xcube version would go into the master branch, others would go into both branches. The master branch could then hold a modified environment.yml permanently, until xcube is eventually released.

This procedure could/should also be extended to the xcube plugins.

@pont-us
Copy link
Member Author

pont-us commented Apr 29, 2021

I think we discussed using a maintenance/master release model at some point recently and concluded that it would be a good idea, but only once xcube development has slowed down and stabilized somewhat. If/when we do go ahead with that, it would certainly help with the version skew problems between xcube and plugins in CI builds. But for now, I think the slightly hacky solution described above should be enough.

pont-us added a commit that referenced this issue Apr 29, 2021
AppVeyor config: add micromamba, install xcube from repo.

Closes #43.
Closes #50.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci related to continuous integration or deployment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants