Use Composer to manage all 3rd-party PHP libraries

[virtualtam]

3rd-party libs shouldn't be part of Shaarli's codebase, but managed and pinned using Composer, and referenced by autoloading (see #607, #608, #612):

• RainTPL: upgrade to 3.1.0, install through Composer #669 - https://packagist.org/packages/rain/raintpl (WONTFIX)
• Use Composer for Parsedown and fix an issue with links #674 - https://packagist.org/packages/erusev/parsedown
• Move Pubsubhub to a default plugin #620 - https://packagist.org/packages/pubsubhubbub/publisher (GitHub)

[ArthurHoaro]

We need to make sure that we're compatible with RainTPL 3.

[virtualtam]

@Marsup wrote:

A quick question as I'm no php expert : would it be feasible or desirable to commit the result of composer into git ? Does composer download system-specific binaries ? From what I read it downloads everything into a vendor folder, if there's no roadblock you could commit that and still keep all the advantages you mentioned.

A quick question, but for sure a tricky one! I've kept rewriting this post over and over for the last hour-or-so, as there are actually very few resources on the Web that address the matter in a structured, argumented way.

So instead of directly answering it, I'll give some pointers to interesting articles and posts I've stumbled upon while digging into the topic :)

• https://developer.atlassian.com/blog/2015/01/even-more-continuous-integration-via-dependency-management-tools/
• https://www.software.ac.uk/resources/guides/defending-your-code-against-dependency-problems
• https://www.gov.uk/service-manual/service-standard
  • https://www.gov.uk/service-manual/technology/maintaining-version-control-in-coding
  • https://www.gov.uk/service-manual/technology/managing-software-dependencies

[Marsup]

Having read all of that, you could still auto-update the dependencies with a git commit hook, also running the test suite to make sure everything's OK. There remains the problem of licensing, but you're probably not using such library.

[nodiscc]

Hi @alexisju you can still install shaarli on shared hosting; but not from git master. You will have to download a prebuilt ZIP at https://github.com/shaarli/Shaarli/releases (it's not there yet). THere will be 2 ways to install:

1. From git (using git clone, or a zipball like https://github.com/shaarli/Shaarli/archive/master.zip). You will get Shaarli's source code without any dependencies, and will have to run composer to fetch them.
2. From a prebuilt release ZIP. This ZIP file will be built by the maintainers (all dependencies fetched using composer) and uploaded to Github. This is the way to go for shared hosting.

[nodiscc]

@Marsup for what it's worth I don't see the point of pulling the 3rd party libs and commiting them to the repo, now that we have proper dependency management. It would make the git repository larger, etc. As I said above, if you don't want to run composer, use a prebuilt ZIP release (not released yet). If you download Shaarli from git you will have to run composer.

[Marsup]

I'll go with composer then. For me it's a much smoother upgrade process to let git manage the file deletion and renames. Using the zip means a much more manual and complex upgrade process.

[nodiscc]

I also use git to upgrade and manage versions and find it smoother than manual operations with ZIP files. Fortunately working with ZIPs can also be automated, and I intend to do that on my own setup soon. I currently use this ansible task to deploy Shaarli, I will do the required changes and post them here if anyone is interested. (basically it will backup the data/ directory, remove the whole shaarli install, download and extract the most recent zip, and restore data/).

There are some disadvantages with the new composer requirement (no more updates via git as @alexisju summarized here - unless you also have composer). I used to oppose this change when Shaarli was a total mess since git was convenient, but IMHO the advantages of having a cleaner codebase (thanks to the fantastic work of @virtualtam and @ArthurHoaro) outweighs this. After all Shaarli used to only be downloadable via ZIP archive on sebsauvage's site.

Let me know if you'd like something to be documented more.

[Marsup]

What are the advised options for a production server ? --no-dev ?

[nodiscc]

I believe yes composer update --no-dev.

@virtualtam can you update

• https://github.com/shaarli/Shaarli/wiki/Upgrade-and-migration
• https://github.com/shaarli/Shaarli/wiki/Shaarli-installation
• https://github.com/shaarli/Shaarli/wiki/Download

with the latest changes regarding the installation procedure? I still think these pages should be condensed in a single one, and the server config examples moved to separate linked pages.

It would be nice to have a Makefile target for installation so that users don't need to figure out composer commands.

[virtualtam]

@nodiscc I've already updated instructions related to the master branch along #607. Instructions for production / stable branch will be updated once a new version is released

[nodiscc]

@virtualtam Ok I just merged the download and installation pages in the wiki, and updated the README to point to the correct page.

https://github.com/shaarli/Shaarli/wiki/Download-and-Installation

[virtualtam]

Thanks @nodiscc ;-)

[virtualtam]

I'm currently working on bumping RainTPL from 2.7 to 3.1, as it's only available from Composer/Packagist starting with 3.0 - https://packagist.org/packages/rain/raintpl

In doing so, I stumbled upon what seems to be an inconsistency in the current templates:

~/dev/shaarli $ ag 'loop=' tpl

tpl/linklist.paging.html
15:    {loop="$action_plugin"}

tpl/tagcloud.html
8:        {loop="$plugin_start_zone"}
14:        {loop="tags"}
17:            {loop="$value.tag_plugin"}
24:        {loop="$plugin_end_zone"}

tpl/page.header.html
37:    {loop="$plugins_header.buttons_toolbar"}
46:        {loop="plugin_errors"}

There are two syntaxes used when looping:

• sometimes over a variable: {loop="$plugin_start_zone"}
• sometimes over a variable name: {loop="plugin_errors"}

Though RainTPL 2.7 doesn't seem to be too picky about it, this leads to RainTPL 3.1 generating erroneous PHP code from templates.

@nodiscc @ArthurHoaro @alexisju @kalvn, did you notice similar issues while working on templates?

I'll do further tests to see if it's possible to get templates that work with both RainTPL versions before actually upgrading to 3.1.

[ArthurHoaro]

It's quite funny, I noticed the same thing today while working on templates. I switched to {loop="$var"} for consistency. Which one is supported by RainTPL 3?

[virtualtam]

{loop="$var"} works fine with both RainTPL versions, #660 submitted to cleanup loop declaration :)