What to package by default?

Development
1

Just continuing to do what I can when it comes to the various builds, in particular right now to a) add a flatpak GitHub Action and b) get the builds somewhat harmonized.

I noticed there’s a bit of a difference between which of the submodules from the OpenChemistry/openchemistry repo are being packaged in each build of Avogadro.

The absolute minimum is of course the main repo + avogadrolibs + avogadroapp.

The current release and nightly builds[1], which build against Qt 5, add:

  • avogadro-i18n* (for localization)
  • crystals*
  • fragments*
  • molecules*

This means they are not packaging:

  • avogadrodata
  • avogenerators*
  • molequeue
  • jupyter-examples

*Everything marked with an asterisk is also available as a plugin through the plugin downloader in Avogadro.

The avogadroapp test builds on the other hand skip all the optional stuff, as do the current preliminary Qt 6 build matrix.

So that I know what to put in the flatpak, what is the current thinking on what should be going into the distributed builds in 2.0/the first release that is built against Qt 6?

Edit: for any future readers the decision was essentially that Avogadro should in general ship with everything marked with asterisks.

  1. I’m sure you told me this somewhere @ghutchis, but I can’t find it now – it’s the avogadrolibs builds that are the source for the releases and get uploaded to provide the nightly builds, right? The AppImage seems to include the molecules library so I’m assuming so. ↩︎

2

avogadrodata is for tests
jupyter-examples is exactly what it sounds - a set of notebooks for using the openchemistry module in Jupyter

But you most likely want avogenerators even though it’s available as a plugin. I’ve gone back-and-forth about which scripts should “ship by default” (e.g., cclib) and which should be download, but I think most people expect a range of generators.

(Ideally, I’d like to see more of the generators split into separate downloads, but that’s a different topic.)

3

Ok, sounds good. Would it be a good idea for me to also add the extra submodules (including avogenerators) to the Qt 6 and avogadroapp workflows then so that everything is the same?

1 Like
4

@matterhorn103 Is this in sync with the guide on Avogadro2?

5

Yeah, if you want to update the GitHub workflows (including avogadroapp) that would be super.

It’s probably also worth copying at least the main build_cmake and qt6 actions to openchemistry so changes in that repo can be confirmed too (e.g., that they work on Windows).

6

Is it possible to somehow share the same set of workflow files between all three repos to save having to keep them all synchronized?

1 Like
7

Remember that each repo has a slightly different checkout action.

There are probably some better ways to keep them better synchronized though – I just haven’t looked into it.

8

Sure, but I thought all this was just drift over time and not actual differences that are needed?

9

Yeah, it’s drift. The real difference between the avogadroapp actions is in the checkout action.

10

Can you enlighten me? Maybe I’m blind… the only difference I can spot is that avogadrolibs explicitly loads crystals/fragments/molecules/i18n, while avogadroapp doesn’t. But doesn’t the recursive clone of openchemistry load all the submodules in both cases anyway?

11

As of three days ago yes, the guide now explains which submodules are necessary, which are optional, and what each optional one broadly adds :slight_smile:

12

Right, but at the moment openchemistry doesn’t guarantee it’s the latest version of all submodules.

13

Ok yeah. Which means that libs/app have the same set of submodules, just at different commits. But is that the desired behaviour? Wouldn’t it be preferable to have both workflows checkout all of the submodules?

14

Yes, exactly. The difference is that a GitHub action for avogadroapp needs a slightly different checkout call to make sure it gets the pull request in question, not the HEAD of the submodule.

You should consider the current avogadrolibs actions as the latest versions - I haven’t bothered to sync them with avogadroapp because that repo gets far fewer pull requests.

15

Ah, I see now. It’s a very very subtle difference :sweat_smile:

So when no repository is specified:

    - name: Checkout avogadroapp
      uses: actions/checkout@v4
      with:
        path: avogadroapp

it will automatically use the current pull request? Whereas when the repo is specified:

    - name: Checkout avogadrolibs
      uses: actions/checkout@v4
      with:
        repository: openchemistry/avogadrolibs
        path: avogadrolibs

it will checkout the current HEAD?

1 Like
16

Right. There are a variety of options for checkout: GitHub - actions/checkout: Action for checking out a repo

But the default one with no repository will “do the right thing” – default to the current commit in a pull request.

They put some thought into the action, so it only fetches a single commit, not the whole history to save time.

1 Like