External repos

[AndreasGocht]

This PR adds the option to Install packages from external repos

[cvonelm]

there are two ruff check warnings. Please fix them.

[cvonelm]

there should probably a class Repo split from the class Store with get_all_packages in the former and get_installed_packages in the latter.

[cvonelm]

It might be ok to push this into a later PR, but we should think about detecting if a user is trying something stupid by first creating a store with repository a, and then adding a package from repository b whose definition is incompatible with the packages from a.

This might cut further into the question of how versioning of packages is done (with semantics of ID X of package a is newer than ID y)

[cvonelm]

Last point, I would be in favour of moving the repo from dpm/repo to something like default_repo in the project top-level to make the weak coupling more apparent.

While keeping it completely separate would be the ideologically nicest way, cloning two repos just seems like a hassle.

[AndreasGocht]

Last point, I would be in favour of moving the repo from dpm/repo to something like default_repo in the project top-level to make the weak coupling more apparent.

While keeping it completely separate would be the ideologically nicest way, cloning two repos just seems like a hassle.

I keep them separate for my self, as I do not want to pollute the main repo with my system specific changes.

However, I do like the idea of having a "default" repo. It might be reasonable to use a subrepo here.

It might be ok to push this into a later PR, but we should think about detecting if a user is trying something stupid by first creating a store with repository a, and then adding a package from repository b whose definition is incompatible with the packages from a.

This might cut further into the question of how versioning of packages is done (with semantics of ID X of package a is newer than ID y)

I do agree, but I would indeed do this in a later PR.

[AndreasGocht]

there should probably a class Repo split from the class Store with get_all_packages in the former and get_installed_packages in the latter.

sounds reasonable. Question is: Who gets the lead? E.g. who manages the solver?
If Store manages Solver, it should manage Repo as well, and vice versa.

[AndreasGocht]

done.

[cvonelm]

sounds reasonable. Question is: Who gets the lead? E.g. who manages the solver?
If Store manages Solver, it should manage Repo as well, and vice versa.

• Solver should get references to Store and Repo

• The Store takes the lead currently. Repo is initialized from --repo, later on we would do it from some metadata in the Store itself (as using multiple different repos with a single store is probably a recipe for disaster)

  • Sidenote, I would like to add an explicit dpm create $STORE_DIR [--repo fobar] command later. Repo should be set once on store creation anyways.
  • Sidenote2: I would like to at some point remove all the print() from Store and split this more clearly frontend <-> backend.

• Store

  • Repo
  • Solver
    • ref to solver
    • ref to repo

[cvonelm]

Also pls rebase, because I hacked together something like a CI

[cvonelm]

I'm getting this error currently

~/sw/dpm % ./dpm.py help
Traceback (most recent call last):
  File "/home/cvonelm/sw/dpm/./dpm.py", line 8, in <module>
    import dpm.pkg_definition
  File "/home/cvonelm/sw/dpm/dpm/pkg_definition/__init__.py", line 2, in <module>
    from .recipe import BasePackageRecipe as BasePackageRecipe
  File "/home/cvonelm/sw/dpm/dpm/pkg_definition/recipe.py", line 11, in <module>
    from dpm.downloader import Resource
  File "/home/cvonelm/sw/dpm/dpm/downloader/__init__.py", line 4, in <module>
    from .git import Git as Git
  File "/home/cvonelm/sw/dpm/dpm/downloader/git.py", line 6, in <module>
    from dpm.types import Needs
  File "/home/cvonelm/sw/dpm/dpm/types/__init__.py", line 5, in <module>
    import dpm.repo
  File "/home/cvonelm/sw/dpm/dpm/repo/__init__.py", line 7, in <module>
    from dpm.types import Package
ImportError: cannot import name 'Package' from partially initialized module 'dpm.types' (most likely due to a circular import) (/home/cvonelm/sw/dpm/dpm/types/__init__.py)