Migration to JuliaGeometry

[mikeingold]

CC: @JoshuaLampert @juliohm

The long-term aim of this package is to be transitioned under the JuliaGeometry organization.

I'll add notes here as I think it through, but here's some details I figure we should iron out:

Package Name/Scope

Should the package name remain MeshIntegrals.jl or change?

What is the intended scope of this package?

• Right now the scope is fairly specific to solving integral problems. I've defined and exported a Jacobian function, which is used internally for calculating differential elements (e.g. the dV for a volume integral), but theoretically could be useful in other contexts. I have visions of AD rules for partial derivatives of Meshes geometry parametric functions, but I suspect those should properly be added to Meshes itself. Are there any other specific interests we should be addressing?

Logistics

How to perform a repo transfer on GitHub?

• I'm assuming it's under Settings > Danger Zone > Transfer Ownership but I've never done this before.
• If the package name changes, do we still perform a repo Transfer or start a new repo with ported contents?

How to handle registry in General?

• If the package name stays the same, how do we re-link the General registry toward the new GitHub page?
• If the package name changes,
  • Register new name in General pointing to new repo
  • How do we gracefully obsolete this package name?

Any changes to maintainers/roles?

Are there any impacts to GitHub Actions being under an organization vs an individual free account?

[juliohm]

Hi @mikeingold, thanks for starting the issue.

Should the package name remain MeshIntegrals.jl or change?

I believe that you already have some notions of differentiation implemented, so I think a broader name would be appropriate. Perhaps MeshCalculus.jl is a good name?

What is the intended scope of this package?

• Right now the scope is fairly specific to solving integral problems. I've defined and exported a Jacobian function, which is used internally for calculating differential elements (e.g. the dV for a volume integral), but theoretically could be useful in other contexts. I have visions of AD rules for partial derivatives of Meshes geometry parametric functions, but I suspect those should properly be added to Meshes itself. Are there any other specific interests we should be addressing?

Perhaps we should list the pros and cons of implementing these AD rules and integrals directly in Meshes.jl before deciding what to do with the migration. These building blocks can be useful in different applications, we just need to figure out where to place dependencies and how to increase integration.

How to perform a repo transfer on GitHub?

• I'm assuming it's under Settings > Danger Zone > Transfer Ownership but I've never done this before.
• If the package name changes, do we still perform a repo Transfer or start a new repo with ported contents?

I think the best option is to create a new package with a different name in JuliaGeometry. That way people can still use MeshIntegrals.jl in the latest version before the migration. The general registry doesn't allow renaming packages, just the URLs where they are host.

Any changes to maintainers/roles?

You guys are the leaders of this development. JuliaGeometry would just be a new home with greater visibility, you would have all admin rights necessary to evolve the project as you wish.

Are there any impacts to GitHub Actions being under an organization vs an individual free account?

I believe JuliaGeometry is also a free account. The actions are run likewise as far as I know. If you had a paid personal account that could be different.

@JoshuaLampert what is your take on the next steps?

[JoshuaLampert]

I mostly agree with everything you wrote above.
Regarding the name I think MeshCalculus.jl is a good name if we want to extend scope to also include proper support for differentials and AD rules and potentially more. However, if this part will live directly in Meshes.jl and will just be used in this package (whatever it will be called), I wonder whether it makes sense to change the name.
I think I slightly tend to implement everything AD related directly to Meshes.jl probably as a package extension using one of the AD packages. In that case this package could use these routines from Meshes.jl and the extension, but still only compute integrals. Thus, a name MeshCalculus.jl could be misleading and MeshIntegrals.jl would be more appropriate.

Regarding the transfer: If we create a new repo in JuliaGeometry and keep this one, we would loose the commit, issue, PR etc. history, which is not that a big deal, but conserving the history would still be nice for future reference. I consider this as an advantage of transferring the repo to the new org without renaming it. We would then follow the steps described here.

Regarding GitHub Actions and similar: I think that should be no big deal. Maybe we will need to add a new DOCUMENTER_KEY and a COVERAGE_TOKEN and similar (or does JuliaGeometry use org wide tokens?), but that should be no problem, I think. The only thing we need to adjust is this line, I assume.

[mikeingold]

For clarity on AD rules, just to make sure we’re all talking about the same thing:

Right now, MeshIntegrals.jl uses general solution methods of the form integral(f, geometry). The differential element is calculated using a Jacobian, taking the partial derivatives of the geometry’s parametric function with respect to each argument. For example, if box = Box(Point(0,0), Point(1,1)), then jacobian(box, (x,y)) for some valid parametric coordinates (x,y) would return (Vec(1,0), Vec(0,1)).

Currently, we’re performing that Jacobian inside this package via a finite-difference approximation. Ideally, some kind of AD rule would be defined, but in my opinion the most appropriate place for those to be defined is in Meshes.jl directly, since that’s where the functions themselves are defined. Defining AD Chain Rules in MeshIntegrals.jl for Meshes.jl functions would be type piracy and also probably fragile to upstream changes.

[JoshuaLampert]

Thanks @mikeingold. I totally agree!

[juliohm]

Makes total sense 💯 Looking forward to AD rules :)

[JoshuaLampert]

Ok, so do I understand correctly that we agree on:

• keeping the name MeshIntegrals.jl,
• moving the repo to JuliaGeometry,
• add AD rules directly to Meshes.jl in the future (probably as a package extension),
• replace the FD formula in MeshIntegrals.jl by the AD rules then defined in Meshes.jl?

If so, I think the next steps are:

• Granting admin rights for JuliaGeometry to @mikeingold (and myself).
• Move the repo via Settings > Danger Zone > Transfer Ownership to JuliaGeometry.
• See if GitHub CI including coverage and Documenter works and potentially fixing it (adding necessary tokens etc.). This includes fixing this line.
• Update the new org in the General registry as described here.
• Adding AD rules to Meshes.jl (some time in the future).
• Replacing the FD formula in MeshIntegrals.jl by the AD rules from Meshes.jl (some time in the future).
• Party 🥳

Did I miss anything or are there any objections?

[juliohm]

@mikeingold was already in JuliaGeometry, I sent you the invitation just now @JoshuaLampert

Please let me know if something else is missing. You should have all rights to transfer the repo.

The general registry has instructions on how to update the URL: https://github.com/JuliaRegistries/General?tab=readme-ov-file#how-do-i-transfer-a-package-to-an-organization-or-another-user

[mikeingold]

Here goes nothing 🤟

[mikeingold]

The package has been transferred to JuliaGeometry and I've got a PR pending to update the General registry

JuliaRegistries/General#117915

[JoshuaLampert]

See also #117 for updating the link to the docs.

[mikeingold]

I just pinged the Slack channel to make sure the General PR doesn't languish.

[mikeingold]

@JoshuaLampert, do you have access/rights to the full repo settings, e.g. tokens, secrets, etc?

[JoshuaLampert]

No, I don't. Do you, @mikeingold?

[mikeingold]

Actually, it looks like I no longer have access to any repo settings. 😕