Harmonize tooling (tox, travis-ci, readthedocs, makefile, ...) with all the birds

[tlvu]

From discussion in https://github.com/bird-house/cookiecutter-birdhouse/issues/99#issuecomment-665766258, we mostly use similar toolchain (tox, travis-ci, readthedocs, makefile, ...) with a few minor difference (ex: preference for pip vs conda).

It would be cool if we can harmonize libraries (ex: xclim or future libraries we will create) with pywps services (ex: the birds) so improvements in one can benefits all the rest.

I wonder if xclim can integrate into the https://github.com/bird-house/cookiecutter-birdhouse.

Currently cookiecutter-birdhouse can only create pywps services. This means changes to cookiecutter-birdhouse to also be able to create libraries (which was the original intend of https://github.com/audreyr/cookiecutter-pypackage where the cookiecutter-birdhouse forked from).

[Zeitsperre]

This is definitely a good idea and it would make it much easier to port the maintenance gains in xclim to other services/libraries we build. Alternatively, we could try configuring a cookiecutter more geared towards libraries like xclim. This was the original intent behind work on https://github.com/Ouranosinc/cookiecutter-pypackage-ouranos.

[tlvu]

Alternatively, we could try configuring a cookiecutter more geared towards libraries like xclim. This was the original intent behind work on https://github.com/Ouranosinc/cookiecutter-pypackage-ouranos.

Yes if integrating 2 cookiecutters into 1 is too complex or possible but harder to understand. But having 2 different cookiecutters means duplicated code and duplicate maintenance effort.

I think we'll have evaluate further the pros and cons, especially for long-term usage/maintenance. Both solutions are on the table for now.

[huard]

I don't foresee a ton of non-pywps libraries. I'm also wary of spending energy on tools that reduce energy spent on tools. Why couldn't we use the vanilla https://github.com/audreyfeldroy/cookiecutter-pypackage ?

[Zeitsperre]

We could, but the scaffolding for pure libraries and PYWPS services is different enough to merit completely different tox, utilities, and CI setups. We could fork this repo to replace the one that I started as I was hoping to push many of the changes to the upstream fork I forked from (the PR is already there: https://github.com/Nekroze/cookiecutter-pypackage).

Right now, the entire range of tests for PyWPS services is run on Travis CI using a .travis.yml. This makes it much harder to test locally, as you essentially have to run the testing suite manually. If we want to be crafting PyWPS-specific services, I would elect that we try an approach using tox. I think we (us and our users) would gain a lot from it.

[huard]

To be clear, I meant we should keep maintaining the birdhouse cookiecutter, but maybe use the standard https://github.com/audreyfeldroy/cookiecutter-pypackage for our other simple python packages.

The fork you forked from looks unmaintained. Why not use the main one ?

[Zeitsperre]

Sure, we can go that route, but I'd still want to jazz it up a bit. If we fork the most recent version, the stuff I'd add wouldn't be too time-consuming. It would mostly be the changes I've implemented in xclim for CI/tox...

And you have a point about the fork. I might work on that one in my personal time. The maintainers are still active and are open to changes (they just don't want something that says "Ouranos" all over it). If no one is bothered, I could take over https://github.com/Ouranosinc/cookiecutter-pypackage-ouranos/ (Miranda is the only project making use of it, I believe) and re-fork https://github.com/audreyfeldroy/cookiecutter-pypackage and implement changes?

[Zeitsperre]

To summarize:

• We refork https://github.com/audreyfeldroy/cookiecutter-pypackage and make a few changes to better facilitate tox and other CI benefits discussed above.
  • I can look into ways of configuring more than one recipe in this fork. One for PyWPS and another for standard libraries. I know this was discussed somewhere (either in cruft or or in cookiecutter).
• I'll make a personal fork of https://github.com/Ouranosinc/cookiecutter-pypackage-ouranos/ and archive it as nothing is really using it and the changes I want to make to the upstream fork fall outside Ouranosinc scope anyway.

Is it safe to assume that prioritizing libraries to make better use of tox is the best approach for local testing (rather than bash/Travis CI scripts running make commands)?

[tlvu]

Is it safe to assume that prioritizing libraries to make better use of tox is the best approach for local testing (rather than bash/Travis CI scripts running make commands)?

Yes for making better use of tox, then in Travis-CI we call the same tox. At my previous job, I've already used the upstream cookiecutter-pypackage and it already had some tox in there, see https://github.com/audreyfeldroy/cookiecutter-pypackage/blob/master/%7B%7Bcookiecutter.project_slug%7D%7D/tox.ini, maybe our cookiecutter-birdhouse fork is too old and we might simply need to sync with upstream to get tox support?

I suggest we simply use the upstream cookiecutter for library and our cookiecutter-birdhouse for pywps service.

We should contribute directly upstream and sync our cookiecutter-birdhouse with upstream so long term we get free "update".

Hopefully, xclim do not have too much "exotic goodies" that upstream will not want it !

[Zeitsperre]

Within the scope of RAVEN and RavenPy, as well as due to changes experienced with the migration of Travis CI to a subscription-based service, I think it's good to refocus this issue.

We refork https://github.com/audreyfeldroy/cookiecutter-pypackage and make a few changes to better facilitate tox and other CI benefits discussed above.

This was done.

I can look into ways of configuring more than one recipe in this fork. One for PyWPS and another for standard libraries. I know this was discussed somewhere (either in cruft or or in cookiecutter).

This turned out to be much too complicated. As @tlvu mentioned, we're much better off making use of cookiecutter-birdhouse anyway.

I'll make a personal fork of https://github.com/Ouranosinc/cookiecutter-pypackage-ouranos/ and archive it as nothing is really using it and the changes I want to make to the upstream fork fall outside Ouranosinc scope anyway.

This was done. Let us speak of it no more.

Is it safe to assume that prioritizing libraries to make better use of tox is the best approach for local testing (rather than bash/Travis CI scripts running make commands)?

Looks like the answer was "yes", haha.

We should contribute directly upstream and sync our cookiecutter-birdhouse with upstream so long term we get free "update".

It appears that cookiecutter is undergoing some major changes (organizationally). This is great since many open PRs have been waiting to be integrated for years now. In fact, lack of movement in the previous master for cookiecutter lead to a discussion on where to go next. One such side project that I'll be looking into is cookietemple: https://github.com/cookiejar/cookietemple.

For now, the cookiecutter template we have forked (https://github.com/Ouranosinc/cookiecutter-pypackage) should be fine. It is currently optimized for RavenPy, integrating some of the goodies from xclim.

[Zeitsperre]

Update 2022:

I want to give an update here and close this issue, as I think we've settled on a working set of tools that should serve for the time being:

• https://github.com/Ouranosinc/cookiecutter-pypackage is now used to maintain all newer pip-installable projects and is kept up-to-date semi-regularly.
• For most of our internal projects, we have adopted make and tox for testing purposes.
• We currently make use of the pre-commit library and accompanying pre-commit.ci webhooks for automated commit fixes and other standard enforcement checks (in our cookiecutter recipe as well).
• While we are heavily invested in GitHub Actions, we maintain an internal GitLab with some CI workflows running (insurance policy if ever Actions pricing changes).

I think this qualifies as enough to close this issue.