Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility with current module installations #11

Open
JJ opened this issue Oct 2, 2019 · 0 comments
Open

Compatibility with current module installations #11

JJ opened this issue Oct 2, 2019 · 0 comments
Labels
question Further information is requested

Comments

@JJ
Copy link
Collaborator

JJ commented Oct 2, 2019

One of the things I'd like Documentable to do is to be able to index, and offer an API, for any modules which are currently installed in the system, and offer them in the same pack. Looking from another point of view, if the "doc" module is installed, documentable should be able to look at it and use it just like it is.
This is not possible now. Pod-To-Cached is creating a parallel precompiled structure. This structure differs, as far as I can see, in several ways from the CURs used to store the Perl 6 modules

  • Actual place where data is stored. Pod-To-Cached uses (the currently called) Document::PrecompilationRepository::Document which uses the name (sans pod6) of the file for directory name, and then precompiles the whole path, which is turned into another long SHA1 before storing the precompiled stuff. The mapping used by zef is probably similar, but also dissimilar enough to not guarantee compatibility.
  • The cache information is stored inside that cached directory for Pod::To::Cached while CUR seems to use the filesystem itself to store the information, relying mainly in version numbers to decide whether the cache is current or not and if neds to install a new version. We keep information about stored date as well as status and a cache-key. The way I see this is that main metadata to know what to store and what not is date for us, version for CUR. Other than that, I don't see a big difference.
  • CompUnits are immutable. Our own is not. I am not sure it's a good thing or a bad thing; it's just incompatible.

The main problem is that we're fumbling our way through the CU stuff. It's mainly undocumented, and we try to replicate some functionality by doing it in some way that kinda works, but we don't really know.

Eventually, we should try and reach compatibility. Module::Pod, kind of does, by finding out where a module is stored and obtaining its documentation. So at the end of the day this issue is mostly a call for giving all this a bit of thought and try and come up with a series of new specs that make this much more useful and usable.

@JJ JJ added the question Further information is requested label Oct 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant