Closed GaryJones closed 5 years ago
A release always references the package it belongs to, so it won't always be an installed package. Say in the future someone defines a package in the admin panel manually through a form and they upload the artifact, that won't be an InstalledPackage
, but it will have one or more releases.
An InstalledPackageRepository
might help in a couple places, but I'd have to see what impact it has on being able to easily decorate repositories.
For Archiver.php, that method signature could probably change to accept an InstalledPackage
instance and a version number instead. For all the others, it looks like those methods should be checking Package::is_installed()
or if the package is an instance of InstalledPackage
first.
This should be fixed by #68.
There's a little bit of mismatch between
Package
andInstalledPackage
, and likewise forPackageRepository
andInstalledPackageRepository
.Consider code like this:
https://github.com/blazersix/satispress/blob/65b9662f910a1b9272f7ac8f1da290904e21ea76/src/Archiver.php#L50-L52
The object returned on line 50 is a
Package
(according to the DocBlock), but the methods called on line 51 and 52 are only contracted byInstalledPackage
.Does a Release always reference an installed package?
Likewise, this code:
https://github.com/blazersix/satispress/blob/65b9662f910a1b9272f7ac8f1da290904e21ea76/src/Route/Download.php#L135
is calling a
get_installed_version()
, which is only defined inInstalledPackage
, yet the repository passed in to the constructor is aPackageRepository
, which is a collection ofPackage
objects, and not specificallyInstalledPackage
objects.A new
InstalledPackageRepository
, containingInstalledPackage
objects would better define the contracts that are currently being assumed.Here are the undefined methods violations: