Start9Labs
Issue viewing marketplace service
Currently, if you are on EmabssyOS < 0.3.0.3 and you try to view the Mempool package, the UI throws and error and freezes.
this.pkg['dependency-metadata'][k]
I believe this is happening because electsrs is a dependency of the latest Mempool, but electrs is not available on EOS < 0.3.0.3. Not sure right away if this is an issue with the FE, BE, or Registry, or all three. Or if this version of Mempool just needed to be pinned to 0.3.0.3. Can we even pin versions of services, or just whole services?
Tagging all parties.
We can actually only pin versions of services. The issue here is that there is no intrinsic dependency of mempool on 0.3.0.3 but apparently there is for electrs.
This definitely requires initial investigation as to why the UI errors/freezes. That should be fixed at a minimum, however, there are significant UX considerations for any solution to that freeze. For instance, do we render dependencies that are unavailable for the current OS? Do we not show dependent services for the current OS if any of its dependencies aren't available for the current OS? How does this work for optional dependencies?
While we can try and diagnose the freeze immediately, however, any solution we settle on will require a discussion.
The reason for the UI freeze is that this.pkg['dependency-metadata'][k] is undefined. Meaning the UI is attempting to display the icon and title of a dependency for which no information can be found.
It seems that the version of Mempool that introduced the dependency on electrs needs to be pinned to the same version of EOS as electrs.
That won't be viable to enforce. For one, we don't "pin" in the way that we used to. Packages specify what version of EOS packed them and there is a set of compatible OS versions. If a service was packed with a compatible OS version, then it can be installed. So consider the following example:
- mempool packed with EOS 0.3.0.2
- electrs packed with EOS 0.3.0.3
mempool may or may not know what version of electrs packed it. It actually has no way to.
As a result, we cannot require that mempool is packed with an OS greater than or equal to the maximum OS version that packed its dependencies.
What we can do, however, is filter it out of the package index on the registry side. If the requester of the index specifies that they only have 0.3.0.2, we can make sure that neither of the above packages displays since we know at the index time all of the information we need to know to guarantee a consistent response that only returns the packages they will be able to get fully installed.
Understood. So we already filter out package versions packed with EOS version > requester EOS version. Now we would need to extend that filtering to include package versions that have dependencies that were packed with EOS version > requester EOS version?
So we already filter out package versions packed with EOS version > requester EOS version.
If there were incompatible APIs introduced between those two version, yes.
Now we would need to extend that filtering to include package versions that have dependencies that were packed with EOS version > requester EOS version?
Yes, with the caveat that it is the same conditions as above.
As a summary of a separate conversation that occurred, consensus has been reached that "packages with dependencies that aren't available at the current version should be treated the same as packages that are not available for the current version".
There are ultimately two scenarios when this will occur:
- The first is when getting packages from the marketplace - the ideal solution here is to verify that the package is incompatible on upload to the registry gatekeeper style - which is ultimately more effective for providing feedback to the developer. This will include filtering for both required and optional dependencies, perhaps showing an error in the former case and warning on the latter. This change needs to take place on the registry.
- The second is when sideloading packages - the ideal solution here is to augment the s9pk to include additional dependency information during bundling.
In the meantime, package developers must be vigilant in self-determining if dependencies within the manifest specified version range are compatible with the SDK version the service is being packaged with.
I'm in favor of renaming this issue to inform development of the second feature and creating a separate issue in the registry for the first.
This is resolved through a combination of hidden flags and willingness to display 404 page if dep not present