raku / toolchain-bikeshed

(ARCHIVE) Discussion area for the Raku toolchain

toolchain-bikeshed

Discussion area for the Perl 6 toolchain

packaging issues

For packaging you will want to build in a temporary directory with an unprivileged user, package the resulting files and make installation mostly just extracting of the resulting archive.

• FIXED: precomp files and the .deps files contain absolute paths which during rpm package build contain $RPM_BUILD_ROOT.
• FIXED: rev-deps have to be re-compiled on installing a package. This needs root and changing of installed files.
• FIXED: .rev-deps files of installed modules have to be changed when installing new modules.
• FIXED: existing files in the short/ directory have to be changed when installing new modules.

possible solutions

• IMPLEMENTED: We're gonna need a way to provide the source file and the path to use as $?FILE separately to the precomp process (requires changes to rather straight forward code in nqp)
• REMOVED: The .rev-deps files should be replaced by directories where you can simply drop in the additions.
• IMPLEMENTED: The files in short/ should probably also be replaced by directories which unfortunatly will incure some runtime cost. This cost may be offset by adding enough information (ver, auth, api) to these files so we only need to load the dist file of the final candidate.

open tickets related to this discussion

• https://rt.perl.org/Ticket/Display.html?id=127031
• CLOSED: https://rt.perl.org/Ticket/Display.html?id=127058

nice to have

• FIXED: Non-SHA filenames for installed modules (this doesn't have to be the case on disk, as long as backtraces include the original filenames)
• IMPLEMENTED: CUR tools to list installed dists, uninstall dists, list dist contents (basically any(rpm|dpkg|pacman) for CUR)
• (for panda) don't install to ~/.perl6 by default if you don't have access to site installation; that, or at least make this configurable. A really nice-to-have would be --site, --user, and --lib (which would install to a custom CUR, much like P5 local::lib).
• META6.json could include a doc_requires for modules used only in DOC blocks.
• The Elm package manager/ecosystem has some notable features I think it would be cool to adopt:
  • The package manager has a diff function that will tell you the differences between two versions of a package (which functions were added or removed, and which functions' signatures changed)
  • The Elm package ecosystem will refuse to accept a package update that changes the interface (removes a function or changes its signature) without bumping the semantic version

toolchain-bikeshed's Issues

Early loading of external CompUnit::Repository

Allow an external CompUnit::Repository to be loaded before regular modules such that they are available to attempt loading from an identity matching their short-id. Something like:

perl6 -CCompUnit::Repository::GitHub -e 'require <github#http://github.com/user/repo.git>; ...'

or the example in the old s22:

CompUnitRepo::GitHub#masak/html-template

Can this be accomplished with CompUnit::Loader if the proper initialization bits are placed in ModuleLoader.nqp? Or will such an external CompUnit::Repository require its own CompUnit::Loader as well?

check out https://spdx.org/licenses/

Platform-specific "depends" clause in META.info

On Unix-based platforms, LibraryMake will be used for building the shared library while on others (like windows) the bundled binary will be used. I need a way to declare such platform-specific dependency as below:

...
"depends-by-platform": {
  "win32" => [],
  "*"     => ["LibraryMake"]
},
...

If there is any hook or another way to do it, please advise.

META6.json needs a module identifier syntax cleanup

Here's a few examples of the sort of thing S22 currently contains:

Foo::Bar
Foo::Bar:auth<cpan:*>:ver(1..*)
Foo::Bar:auth<cpan:baz>
Foo::Bar:ver(v1.0 .. *)

It's wildly inconsistent, there's barely any mention of which forms are allowed in which keys, and some of these uses of :ver would be a nightmare to parse in what's supposed to be a declarative file. So let's fix it.

I've got a rough set of ideas to start with:

• No part of dependency specification should require a bare, unversioned module name like Foo::Bar. That means any part of the toolchain that currently restricts it this way is broken. To name one example, it's not possible with the current state of affairs to publish a package that provides Foo:ver<1> and Foo:ver<2> at the same time: if you're lucky only one of them will fail to install.
• The various bits like :auth<> and :ver<> should be limited to non-Turing-complete syntaxes so people won't have to load an entire Perl 6 runtime to parse them, which probably means limiting to strings inside angle brackets, and simple ranges. For the sake of argument, I'd consider :ver(v1.9.2 ^..^ v2) simple enough.
• Foreign libraries exist and we need to deal with them. It wouldn't make sense in Perl 6 code (yet), but META6.info could have some syntax like {"depends":["sqlite3:from<native>:ver<0.8.*>"]} to depend on a system libsqlite3.so.0.8.6. Package installers would then be allowed to reconcile those deps whichever way they see fit (other packages could even list them in provides, if they know how to do so).

Anyway, I'll go ahead and add this to the perl6/specs meta-v1 branch later on if nobody yells "stop".

Option to disable precompilation fallback

I've had a couple of times where I released a module which breaks pre-compilation.
It hits one of the precomp bugs, fails to compile, falls back to compiling the original source, but I don't notice it because prove doesn't show it. I want the ability to disable precomp fallback, so it just dies completely.

I think it might be good idea to disable it for make spectest too and see what comes up.

An environment variable would be handy but I guess a pragma like no precomp-fallback could work too.

I think I am talking wrapping this line in an if statement: https://github.com/rakudo/rakudo/blob/nom/src/core/CompUnit/Repository/FileSystem.pm#L78

Thoughts?

EDIT note: I think I should mention that in general precomp is working great so (@niner)++. It has cut one of my project's startup time from around 40s to 1s. I love it so much that I want to make sure that my changes don't quietly break it!