search

mne-tools / mne-installers

Installers for MNE-Python.
BSD 3-Clause "New" or "Revised" License
9 stars 8 forks source link

Update to latest constructor fork #131

Closed hoechenberger closed 1 year ago

hoechenberger commented 2 years ago

We pinned constructor to a specific version. We should bump to the latest release of the fork we're using, adjust our patches if needed, and then try to get part of that stuff merged "upstream" in the fork :)

larsoner commented 2 years ago

@hoechenberger have you followed https://github.com/conda/constructor/pull/475 et al.? Any idea if we're close to being able to use the non-forked version?

hoechenberger commented 2 years ago

I have to say Unlust track because there were so many changes. There is an issue at the napari repo where they're tracking progress I believe, maybe we should try to follow that one 😅

larsoner commented 2 years ago

I did a search there for "conda constructor" and didn't find anything obvious. Is it possible it's in one of the conda constructor/packaging forks rather than napari?

hoechenberger commented 2 years ago

I will take a look and try to find it :)

larsoner commented 2 years ago

FYI I plan on trying to get one of those properly signed Windows certificates for us to use, too

larsoner commented 2 years ago

... do you happen to know if we can get away with standard code signing, or if we need EV code signing for windows?

hoechenberger commented 2 years ago

Cool!

A little bit of google'ing seems to suggest that the warning message (Windows SmartScreen) only goes away if the executable has been signed with an EV cert.

hoechenberger commented 2 years ago

@larsoner I believe once https://github.com/conda/constructor/pull/474 has landed we should just try and see if we can use constructor & menuinst vanilla.

I do remember that the napari fork of menuinst behaved quite differently from the vanilla one. But I don't remember in which way exactly … but there was an important, major difference. Related to when and how the menus are created or so …

I'd say for 1.2 we should still use the napari fork if it still works.

larsoner commented 2 years ago

Found the meta issue

https://github.com/napari/packaging/issues/15

jaimergp commented 2 years ago

Hi team! I'll give you a short overview of where we are at. conda/constructor:main now has almost everything the napari fork had, plus more! Upstreaming the changes one by one, plus individuals review, pushed the code further in terms of robustness and QC.

The only thing missing right now is https://github.com/conda/constructor/pull/474. This PR is part of a bigger, cross-tool change: bringing cross-platform shortcuts to conda. It additionally involves a full menuinst rewrite, a new JSON metadata schema for menus, a PR in conda, and a conda-standalone repack. The bundle_tools channel has packages with all these changes.

I am working now on bringing the original 474 up-to-speed with main so I can repackage all the pieces of the puzzle. I'll probably push them to a new label so it doesn't break anything. Subscribe to the napari/packaging issue to stay up to date!

hoechenberger commented 2 years ago

This is amazing work, @jaimergp! Thanks for the update!

If you have a minute to spare – could you please remind me what was the difference between vanilla and napari's menuinst? I do remember that there were important differences, but I cannot remember which…

jaimergp commented 2 years ago

Vanilla menuinst only supports Windows shortcuts. The new menuinst will provide shortcuts for Windows, macOS and Linux, using a new JSON configuration schema.