Installing A Custom Composer Package from GitLab

Question

I've created a simple test wordpress plugin. The plugin consists of a single php file (kreplach.php) and a composer.json:

kreplach.php

<?php
    /*
    Plugin Name: kreplach
    Plugin URI: http://gitlab.example.com/sales/kreplach
    Description: just a test
    Author: Foo Bartok
    Version: 1.0
    Author URI: http://example.com
    */
?>

composer.json

{
    "license": "MIT",
    "name": "sales/kreplach",
    "type": "wordpress-plugin",
    "description": "just a test",
    "authors": [
        {
            "name": "Foo Bartok",
            "email": "[email protected]",
            "homepage": "example.com"
        }
    ],
    "require": {
        "composer/installers": "*"
    }
}

On my dev server I have the following composer.json

Server's composer.json

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://wpackagist.org"
        },
        {
            "type": "vcs",
            "url": "[email protected]:sales/kreplach.git"
        }
    ],
    "require": {
        "php": ">=5.4",
        "wpackagist-plugin/akismet": "*",
        "wpackagist-plugin/contact-form-7": "*",
        "wpackagist-plugin/wordpress-importer": "*",
        "sales/kreplach": "master",
        "johnpbloch/wordpress": "4.*",
        "composer/installers": "*"
    },
    "extra": {
        "wordpress-install-dir": "wp"
    }
}

What I think SHOULD happen:

1. Composer looks through the git repo for composer.json
2. Composer matches the name "sales/kreplach" found in the build host's composer.json
3. Composer copies the contents of the master branch into wp-content/plugins/kreplach on my build host.
4. My fake plug-in does nothing, as designed.

What actually happens:

Bitter, bitter failure.

Loading composer repositories with package information Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested package sales/kreplach could not be found in any version, there may be a typo in the package name.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
     see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.

Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

I have tested cloning the sales/kreplach repo onto the same host I'm attempting to install the plugin on.

To make sure that composer is actually reading the composer.json file from the git repo, I introduced a typo (yeah, totally on purpose, like) which threw a "hey, this json file is broken, Foam Head" error.

My version of gitlab is omnibus edition 8.6.4 (installed today).

I have successfully done this same sort of trick with pip/requirements.txt to install custom python modules, so I'm not unused to following directions. Am I missing a step, or some sort of non-obvious (to me at least) nomenclature?

Answer 1

Update 2021, 5 years later, since GitLab 13.3 (Aug. 2020), GitLab (even in its free edition) has a Package Registry, establishing GitLab as a private repository.

You can publish in it Composer packages, and, with GitLab 13.11 (April 2021):

Use Composer v2 with the GitLab Package Registry

You use Composer to publish, share, and download your PHP dependencies to your GitLab Project. Six months ago, a new major version (v2) of Composer was launched with a variety of changes, including significant performance improvements, architectural updates, and runtime features.
You can read more about the changes here.

Until recently, you couldn’t take advantage of these improvements because the GitLab registry didn’t support Composer v2.
This prevented some of you from using the GitLab registry at all.

As an MVC, we focused on adding support for the mandatory parameter metadata-URL. We added a new endpoint GET group/:id/-/packages/composer/p2/:package_name, which returns the metadata for all packages in your repository.
When Composer looks for a package, it replaces %package% with the package name and fetches that URL.

This means we’ve added a new endpoint GET group/:id/-/packages/composer/p2/:package_name which will return the metadata for all packages in your repository.

Please note that there are two parameters considered optional.
We have issues open to add support for the providers-api and list-api parameters. We hope to prioritize them in an upcoming milestone.

See Documentation and Issue.

And (still GitLab 13.11, April 2021):

Download Composer dependencies from version control

You have two options when downloading Composer dependencies: source or dist. For stable versions, Composer uses dist by default and downloads the dependency as a zip file.

However, you can also download it directly from version control.
If --prefer-source is enabled, Composer downloads your dependency as a Git clone instead of as a packaged zip file.

This is useful if you want to make a bug fix for a project and get a local Git clone of the dependency directly.

Until recently, you could not use the prefer-source and related preferred-install commands and configurations when downloading Composer dependencies.
This prevented many of you from using the GitLab Package Registry for your Composer dependencies.

We are happy to announce that you can now download your Composer dependencies from source.
Do so by simply adding the prefer-source option to your install command like this: composer update --prefer-source.

See Documentation and Issue.