You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue #39 identifies how the use of mach-nix for liberaforms (which uses an IDF) depended on an old version of nixpkgs as a workaround to a bug a with mach-nix DavHau/mach-nix#549 which made it incompatible with newer versions of nixpkgs. That is documented here: https://github.com/ngi-nix/ngipkgs/blob/main/pkgs/liberaforms/env.nix#L9-L16 it was from back in June when we set up ngipkgs with liberaforms as the initial test service.
Since then, I see that in early July a new PR was merged for mach-nix DavHau/mach-nix#563 that apparently fixes the incompatibility with newer nixpkgs. Assuming this fix works, then in theory this issue could be resolved by sourcing the import of mach-nix for liberaforms from its master branch (to include the fix) and then removing the old nixpkgs workaround. I tried this here: https://github.com/ngi-nix/ngipkgs/tree/remove-old-nixpkgs but ran into the following error (which was also problematic in earlier iterations of packaging liberaforms):
Some requirements could not be resolved.
Top level requirements:
alembic==1.7.5 attrs==21.4.0 Babel==2.9.1 beautifulsoup4==4.10.0 bleach==4.1.0 cachelib==0.5.0 certifi==2021.10.8 cffi==1.15.0 charset-normalizer==2.0.9 click==8.0.3 cryptography==36.0.0 dnspython==2.1.0 email-validator==1.1.3 feedgen==0.9.0 F>
Providers:
{'_default': ['wheel', 'sdist', 'nixpkgs'],
'gdal': ['nixpkgs'],
'pip': ['nixpkgs', 'sdist'],
'setupmeta': ['wheel'],
'setuptools': ['nixpkgs'],
'wheel': ['nixpkgs', 'sdist']}
Mach-nix version: master
Python: 3.10.12
Cause: Requirements conflict: cryptography (<SpecifierSet('==36.0.0')>,)
The requirements which caused the error:
cryptography (<SpecifierSet('==36.0.0')>,)
The given requirements might contain package versions which are not yet part of the dependency DB
currently used. The DB can be updated by specifying 'pypiDataRev' when importing mach-nix.
For examples see: https://github.com/DavHau/mach-nix/blob/master/examples.md
As discussed in #24, the use of an IFD by mach-nix for the liberaforms package is already a problem for CI performance, and there are likely going to continue to be problems with mach-nix since it doesn't seem to be very actively maintained anymore. Therefore this new issue with mach-nix raised in issue #39 is adding to a growing list of reasons to disable liberaforms in ngipkgs until further work can be done on it to transition away from the use of mach-nix and IFDs, perhaps also as part of updating the packaging to a new version 3.0 of liberaforms which looks like it could come out sometime in the next year.
Issue #39 identifies how the use of mach-nix for liberaforms (which uses an IDF) depended on an old version of nixpkgs as a workaround to a bug a with mach-nix DavHau/mach-nix#549 which made it incompatible with newer versions of nixpkgs. That is documented here: https://github.com/ngi-nix/ngipkgs/blob/main/pkgs/liberaforms/env.nix#L9-L16 it was from back in June when we set up ngipkgs with liberaforms as the initial test service.
Since then, I see that in early July a new PR was merged for mach-nix DavHau/mach-nix#563 that apparently fixes the incompatibility with newer nixpkgs. Assuming this fix works, then in theory this issue could be resolved by sourcing the import of mach-nix for liberaforms from its master branch (to include the fix) and then removing the old nixpkgs workaround. I tried this here: https://github.com/ngi-nix/ngipkgs/tree/remove-old-nixpkgs but ran into the following error (which was also problematic in earlier iterations of packaging liberaforms):
As discussed in #24, the use of an IFD by mach-nix for the liberaforms package is already a problem for CI performance, and there are likely going to continue to be problems with mach-nix since it doesn't seem to be very actively maintained anymore. Therefore this new issue with mach-nix raised in issue #39 is adding to a growing list of reasons to disable liberaforms in ngipkgs until further work can be done on it to transition away from the use of mach-nix and IFDs, perhaps also as part of updating the packaging to a new version 3.0 of liberaforms which looks like it could come out sometime in the next year.
Tracking issue: #12
The text was updated successfully, but these errors were encountered: