I activated the environment with .akku/env and now I can't import one of my libraries, why?
You probably need to run akku install again. The only directory in the Scheme search path is .akku/lib, which means that you'll need to run akku install again if you create a new library file in your project.
How do I get verbose logging from Akku?
Run Akku like env AKKU_LOG_LEVEL=trace akku ... to get trace-level debugging. Less verbose levels are available; see the manpage.
Is Akku tied to some particular Scheme implementation's community?
No, Akku is not heavily tied to any community. Packages for any implementation can be published to Akku.
Akku currently needs Chez Scheme or GNU Guile to run, but this is mostly due to lack of volunteer time for porting it to other implementations.
Why isn't FOO version i.j.k in Akku?
Likely because nobody has published it yet. You can do it yourself with the akku publish command in the project's git repo. See the manpage for more info.
I have an R7RS package, should I upload it to Akku?
No, it's better to upload it to http://snow-fort.org/. Then it will be available to Snow and Akku users.
How does the R7RS support work?
Akku searches packages for define-library forms and installs them to .akku/lib both as the original .sld file, but also as translations to .sls files. The translation cannot fix libraries that are naturally non-portable, e.g. libraries that depend directly on a Scheme's built-in libraries, but it does handle the differences between define-library and library. The akku-r7rs package provides the R7RS-small libraries.
If a library contains R6RS implementation names in the library-level cond-expand then multiple implementation-specific .<impl>.sls files may be created, since R6RS does not have its own cond-expand on this level.
Packages from http://snow-fort.org are semi-regularly reviewed and uploaded to Akku's index.
Why are there no library names in the manifest, how does Akku know what libraries come with my package?
This is one of the unique things about Akku and needs some context to be explained.
Akku splits its work into multiple stages. Akku.manifest lists some basic information about the current package, and which dependencies it has. The dependencies are fed to a dependency solver that uses Akku's index to find a concrete set of versions that satisfy the dependencies. These are written to Akku.lock and are used for the next stage, which is to fetch the source code. Akku now downloads all source code to .akku/src and verifies checksums.
The next stage is where Akku finds out what libraries there are. It scans every file in .akku/src/<pkg> and does an analysis to find out what kind of file it is and what its library name is. It also determines if the library is implementation-specific and what its imports and exports are. You can use akku scan in a directory to find out what Akku thinks about a project's files.
The information from the scan is passed to the next stage, which is installation. Akku constructs file names for all the libraries it found, based on how various Scheme implementations implement their library search procedures. Some implementations (e.g. Ikarus) URL-encode library names so that (srfi :1) becomes srfi/%3a1.sls and some don't do that (e.g. Chez). Akku therefore installs (srfi :1) to both srfi/%3a1.sls and srfi/:1.sls, and any other necessary locations below .akku/lib. Neither the person writing a library, the person packaging a library nor the person using a library should need to know where that library needs to be installed. The reason all this works is because libraries have their full name written in the source code.
tl;dr: Akku finds all libraries and knows where to install them so that all supported Schemes can find them.
How do I override a library in one of my dependencies?
After akku install you'll find the source code for your dependencies in .akku/src. Copy the files you want to override into your own project, edit them and commit them. Next run akku install and you'll find that .akku/lib has now replaced the overridden files with the versions from your own project. This is by design. Packages are installed in the order written in Akku.lock, followed by the current project. A message is printed when a library is overriden in this way so that you can see if your dependencies are doing it themselves.
What's up with the logo and the name?
The logo has the Lispy parenthesis, but it's really a lime with a copper and zink plate in it. So it's a fruit battery, which goes with the European word "akku" that means battery. Scheme doesn't come with the batteries included; an Akku is needed.
Package repositories like NPM, RubyGems and PyPI have had backdoor problems, what about Akku?
All packages in Akku's index have been manually reviewed before they went into the index. Cryptographic hashes ensure that nobody can later replace a reviewed version with a backdoored one.
The archive itself is at https://archive.akkuscm.org/archive/. The index is regenerated from the .akku files in /archive/packages, each of which has an OpenPGP signature that was generated when the package was first published. The index file has an OpenPGP signature that is verified by akku update. The signatures can also be verified with standard tools like GnuPG.
Downloaded source code is either verified with a Git commit hash or a SHA256 of the tarball. These are included in the .akku file and the index.
When you publish a package with akku publish it is signed with your OpenPGP key. One consequence is that someone with direct access to the index can't change your package and still claim that it's the original version you published.
Should I commit the .akku/lib directory (etc.)?
It's really up to you, but it shouldn't be necessary since your users can reconstruct that directory with Akku. Do commit the Akku.manifest and Akku.lock files.
If you do decide to commit the directory then you may wish to prune the library set first. Akku itself uses a git pre-commit hook to do that: https://gitlab.com/akkuscm/akku/blob/master/pre-commit-refresh
Are there any examples of running Akku in Travis CI (etc.)?
Yes. Here are projects that use Travis CI:
- https://github.com/weinholt/zabavno/blob/master/.travis.yml
- https://github.com/RhysU/ndarray/blob/master/.travis.yml
There are some drawbacks with this solution. Very often the key servers do not respond. There's also a lot of fiddly stuff that happens behind the scenes to make everything work, such as fetching and/or compiling the Scheme implementation, so there is occasionally some overhead when the compiler is not in the cache. Akku itself uses this setup to run CI tests on macOS.
Here is a GitLab project that uses the FFI and is based on a Docker image with Alpine Linux and Chez Scheme:
The forward roll in before_script (apk and yes) is needed for the FFI (or script hooks in Akku.manifest, to be more precise). More Docker images are available, have a look at the tags on https://hub.docker.com/r/akkuscm/akku
Here is a GitHub project that uses Circle CI to run tests in a few implementations, and completely fails: