Implement PathMappingRepository

[webmozart]

At the moment, Puli uses the FilesystemRepository to mirror the resource repository on the filesystem. This repository works well on Unix, but has problems on Windows. Often, symbolic links are not supported on Windows. In that case, FilesystemRepository creates copies of the resources. Consequently, puli build needs to be called after every change to a file to update the copies - which clearly is not user friendly.

To solve this problem, a PathMappingRepository should be implemented that uses a KeyValueStore as backend:

use Puli\Repository\Api\EditableRepository;
use Webmozart\KeyValueStore\Api\KeyValueStore;

class PathMappingRepository implements EditableRepository
{
    public function __construct(KeyValueStore $store, $optimize = false)
    {
        // ...
    }

    // ...
}

The repository supports adding FilesystemResource objects only. It should support two modes:

• $optimize = false (the default): In this mode, the repository stores only the mappings from Puli paths to filesystem paths added via add(). Paths inside those mapped paths are resolved at runtime, so that new or changed files are recognized.
• $optimize = true: In this mode, the repository traverses added resources recursively and adds all path mappings from Puli paths to real paths. At runtime, the repository only needs to check whether and where a path is mapped. If a path is not mapped, the repository fails immediately.

[tgalopin]

@webmozart Should we require or only suggest https://github.com/webmozart/key-value-store in composer.json? I would be in favor of suggesting it as the PathMapping repository is a useful but optionnal tool. What do you think?

Btw, I'm working here: https://github.com/tgalopin/repository

[webmozart]

Yes, I think so too! Thanks @tgalopin :)

[tgalopin]

I worked on the optimized path mapping repository (https://github.com/tgalopin/repository/tree/path-mapping) and made it fulfill the tests (https://travis-ci.org/tgalopin/repository).

I made a pull request (WIP) to discuss the code. The tests are not completely finished for the optimized version and I'll finish them before starting the classic version.

[tgalopin]

What happen on the removal of a resource in the PathMappingRepository (without optmization)? Should we remove the file behind it or should we store somewhere that this resource shouldn't be accessible anymore (through this repository)?

[webmozart]

@tgalopin As I said before, remove() doesn't make much sense for the non-optimized repository. You can support clear() (which removes all mappings, but not the physical files), I think that's enough.

From remove(), simply throw a BadMethodCallException.

[tgalopin]

I'm working on the development version of the PathMapping repo:

https://github.com/tgalopin/repository/blob/dev-path-mapping/src/PathMappingRepository.php

For the moment, I handle the resources in two different ways:

• the "virtual" resources (ressources added by add() and their parents) are stored in the store ;
• the "filesystem" resources (resources existing on the filesystem) aren't stored in the sotre and are resolved at fetch time ;

But I've a problem with search and glob interpretation: how can I execute a glob on these two types of resources at the same time? For the moment, the only viable idea I have is to find the shared directory without glob element (for instance, it would be /tgalopin/dir1 for glob /tgalopin/dir1/*/{foo,bar}*.txt), find all the children of this directory and iterate on the results with the GlobIterator. It's not very sexy and I guess it wouldn't be efficient.

What do you think? Perhaps is my storage structure the problem, don't hesitate to give your opinion :) .