Store package list in .puli/packages.json by default

[webmozart]

Right now, the installed packages are stored in the "packages" key of the project's puli.json file. This file is usually versioned. Most people use Composer to manage their packages, so whenever they do composer install or composer update, this list may change (similar to composer.lock).

In order to prevent this, we should add two new configuration keys to Puli:

• package-list.path: The path of a JSON file that stores the package list. Default: .puli/packages.json
• package-list.inline: Whether to store the package list in puli.json. Default: false

When package-list.inline is set to true, Puli behaves like it does right now and stores the package list in puli.json.

When package-list.inline is set to false (the new default), Puli will store the package list in the path given in package-list.path (.puli/packages.json by default).

[sagikazarmark]

When a package is added/modified using the cli, package-list.inline should automatically be set to true.

[webmozart]

@sagikazarmark Sure? You could also version the packages.json directly (and for example move it to the root). This seems like a bit too much magic to me.

[sagikazarmark]

You can't move it to the root if you have node dependencies as well, but you are right, you can still version the file in the .puli folder. Although that's another source for confusion which I mentioned earlier somewhere: managing configuration in two separate files. But I guess it is up to the user to handle this scenario then.

[webmozart]

@sagikazarmark I agree. I think we should add a page in the documentation where we describe how to manually manage packages. This documentation includes setting the configuration key and how to use the puli package command. With that this shouldn't be too hard.

[mnapoli]

:+1: that would be awesome, I've always been slightly bothered by this seemingly dynamic list being versioned in git ;)

[gossi]

I like the idea of having a "public" and a "private" area. Public is, where a user/developer operates, typically puli.json. All changes in puli.json are made by the developer itself, either manipulating the file manually or running a cli command. The file belongs to the user, puli itself shouldn't change anything there (as it is typically versioned). Instead all storage puli creates itself should go in the "private" area. In case of composer this is vendor/ and composer.lock. Whatever this might be in puli, I'm happy as long as my file stays untouched. I like the composers idea here. It defines defaults (e.g. the vendor/ directory) but those can be overriden in the config section of composer.json. If that pattern can be reapplied to puli, this is something most devs are already aware of and can start through immediately.

[sagikazarmark]

@gossi be aware that the behavior is either one or the other. If you mix manual package definitions with composer, you will still have to maintain a list which might be modified by composer. This is only useful when you have composer-only puli packages in which case, the list does not have to be version controlled.

But if the two approaches are mixed (composer and manual packages) then the full package list must be version controlled.

[webmozart]

Well, we could additionally add the config keys package-list.<installer>.path and package-list.<installer>.inline that allow to move the packages for a specific installer name to a separate file. Then we could set

{
    "config": {
        "package-list.inline": true,
        "package-list.composer.inline": false,
        "package-list.composer.path": ".puli/packages.json"
    }
}

by default.

[CodeCures]

i've been trying to install puli but dont know how....is there a way anyone can help?