Turn ComplexesCategories into a suggested dependency of QPA?

[zickgraf]

Having QPA depend on ComplexesCategories causes various issues, e.g. that everything that depends on QPA now also depends on Locales. From a quick local test it looks like this dependency is not used for anything we need: I have removed the dependency, and commented the following lines in read.g:

#ReadPackage( "QPA", "lib/homologicalalgebra.gi" );
#ReadPackage( "QPA", "lib/complexity.gi" );
#ReadPackage( "QPA", "lib/ext.gi" );
#ReadPackage( "QPA", "lib/transpose.gi" );

With this, the tests of Algebroids pass without problems. So probably ComplexesCategories could be turned into a suggested dependency and the above files could be loaded conditionally.

@mohamed-barakat @kamalsaleh Could you check if this works for all of your applications, too? It would be very nice if we could simplify the dependency tree :-)

[mohamed-barakat]

Looks good for me.

[mohamed-barakat]

We need to coordinate with @sunnyquiver.

[kamalsaleh]

Sounds also good for me.

[zickgraf]

I have pushed a version of QPA2 which has ComplexesCategories as a suggested dependency to homalg_project: homalg-project/QPA2@3a49ae5 We can test this a bit and if it does what we want, we can create an official PR.

[sunnyquiver]

I have contacted Øystein, since he is more into the inner workings of QPA2. It was unclear to him why ComplexesCategories must depend on Locales, as this dependency was entered into ComplexesCategories recently without any explanation why this was needed. Here is a further quote from Øystein thanks to Google translate:

"And I also can't see why it is problematic that you get one a dependency to the Locales package. But if by one or the other
reason is problematic to depend on that package, then it works for me as if the most obvious solution would be to change back in ComplexesCategory so that it no longer depends on Locales. But I don't know what was the reason why that dependency was added to -- in that it was not explained in the commit message.

On the other hand, I don't see that there will be any big problem either to do as they suggest, i.e. to make QPA2 independent of ComplexesCategory. It probably just means that if you only load QPA2, then you can't make chain complexes -- but if you also load ComplexesCategory, then you can create chain complexes.

To summarize: I see no problem with doing the one suggested the change in QPA2, but I also fail to understand the rationale for do it."

I second Øystein's opinion as he is the one who knows QPA2.

[kamalsaleh]

The objective was that we wanted to construct the complexes category of a category $C$ as a functor category from the category of integers to the category C; i.e., $\mathrm{Ch}(C) \simeq \mathrm{Hom}(\mathbb{Z},C)$ and the package Locales provides a constructor for the category of integers as a (proset category).

However, since the category of integers is (indeed) not involved in any real computations in complexes, I decided to revert the commit which introduced locales as dependency and impelement the category of integers manually as it takes not more than 10 lines of code. If the functionally of Locales turns out to be needed, then one can still load Locales first. The new implementation of the category of integers will then take into account wheather locales is marked for loading or not.

--> For now, no action needs to be taken in QPA2.

[kamalsaleh]

Addendum: I have created a PR which turns Locales into a suggested package in ComplexesCategories. However, the package PreSheaves, which is now a dependency of ComplexesCategories, might require Locales in the next few weeks.

Ultimately, we hope, using CompilerForCap, to even turn PreSheaves into a suggested package. So that the current categorical towers and their many dependencies are needed only to generate a compiled code, which can afterwards be excuted without the need to the towers or their dependencies. This would be similar to how the current LinearAlgebraForCAP is nothing but a compiled code of a tower located in FreydCategoriesForCAP without even requiring FreydCategoriesForCAP as a dependency.