私有作曲家包 - 没有找到有效的composer.json

时间:2013-11-12 10:54:09

标签: php composer-php package-managers

我正在尝试使用作曲家加载我在BitBucket上托管的库,如official documentationhere中所述,但仍然收到以下错误:

[Composer\Repository\InvalidRepositoryException]
No valid composer.json was found in any branch or tag of [repository URL], could not load a package from it.

这是我的项目 composer.json:

{
    "name": "Project name",
    "require": {
        "my-vendor/my-package": "dev-master"
    },
    "repositories": [
        {
            "type": "vcs",
            "url": [repository URL]
        }
    ]
}

这是我的远程存储库中的composer.json(显然无法找到):

{
    "name": "my-vendor/my-package",
    "version": "0.3",
    "autoload": {
        "psr-0": {
            "NS_": "src"
        }
    }
}

我应该提一下,两个composer.json文件都应该在根目录中。

其他一些注意事项:

我也试着“非作曲家封装”的方法,借此我指定在我的项目composer.json包信息,以及从我的远程仓库省略composer.json,如在概述的documentation 。这成功克隆了主分支,但随后导致以下错误:

[RuntimeException]
Failed to execute git checkout "master" && git reset --hard "master"

fatal: Not a git repository (or any of the parent directories): .git

然而,该软件包按预期下载到/ vendor,所以我不确定为什么它会再次检查master。

这不是我希望解决此问题的方式(因为我宁愿在远程存储库中使用composer.json),但它可能有助于在其他地方识别问题。

感谢您的帮助。

修改

我设法通过HTTP引用package.json来实现它:

"repositories": [
    {
        "type": "composer",
        "url": "http://localhost/packages.json"
    }
]

packages.json看起来像:

{
    "packages": {
        "vendor/my-package": {
            "dev-master": {
                "name": "vendor/my-package",
                "version": "dev-master",
                "source": {
                    "url": [repository URL],
                    "type": "git",
                    "reference": "master"
                }
            }
        }
    }
}

这是让这个工作的唯一方法吗?如果我只使用一个或两个内部软件包,那么托管我自己的packages.json文件似乎有点过分。

无论如何,这给了我与之前提到的相同的Git错误。

编辑2

强制发生错误(无效的SSH密码)会产生以下结果:

[RuntimeException]
Failed to execute git clone "[repository URL]" "C:\workspace\DFv3\vendor\vendor/my-package" && cd /D "C:\workspace\DFv3\vendor\vendor/my-package" && git remote add composer "[repository URL]" && git fetch composer

所以我可以清楚地看到它在这里做了什么。但是,似乎之后,此命令将cd运行到.git目录并尝试运行:

git checkout "master" && git reset --hard "master"

大概要摆脱它所拉的作曲家实例。但是,它在错误的目录中运行它,我无法弄清楚为什么..

6 个答案:

答案 0 :(得分:7)

如果库的composer.json实际上由受支持的源控制系统管理,则不得在库的composer.json中包含version规范。目前你说你的主分支是版本0.3(这是一个稳定的版本),但你试图包括“dev-master”(这是一个不稳定的版本)。如果该软件确实是“dev-master”或“version 0.3”,那么Composer可能会感到困惑。

如果您确实在主分支中为0.3.x系列开发新版本,则应该定义分支别名。将其添加到当前版本0.3.x的开发分支中:

"extra": {
    "branch-alias": {
        "dev-master": "0.3.x-dev"
    }
}

如果你想继续使用版本0.4或1.0,你将使用名为“0.3.x”的分支在0.3系列的“last”状态下进行分支,然后将master分支中的composer.json更新为将dev-master指向一个新别名(如"dev-master": "0.4.x-dev")。您也可以根据自己的喜好命名旧的0.3分支,然后为THAT分支添加别名。

执行此操作将使您能够要求使用0.3.x的最新开发版本:

"require": {
    "my-vendor/my-package": "0.3.*@dev"
}

这将提取最新的0.3版本 - 由于定义的别名,它目前将成为主分支中的最新提交。

您当前设置的方式会强制您明确包含版本0.3,这是一个移动目标,而不会明确地知道该事实。

只有在没有可用于为Composer提供版本号的版本控制系统,即没有可用的标签,或者标签不符合Composer对版本号的要求时,才应提供显式版本标签。由于您似乎可以控制这些vcs,因此最好使标签符合Composers标准,而不是让发布新版本变得麻烦。

修复此问题后,我确实希望您的安装不再需要package.json文件,因为该文件现在可以修复您使用该版本声明创建的问题。那时你也不再需要那个作曲家参考,但可以像你一样回到提到原始存储库。

如果您觉得自己使用的私有存储库太多而且需要更多的私有存储库,并且厌倦了在长列表中提及它们,那么您可以考虑使用Satis创建这样的已发现列表包而不是手动创建它们。

答案 1 :(得分:4)

我有同样的错误,从 vcs 删除文件夹后一切正常

sudo rm -R ~/.composer/cache/vcs/*

在Windows上(如@Serbu建议):

  

清除下面的vcs,repo和files目录   C:\用户\我\应用程序数据\本地\作曲\

答案 2 :(得分:3)

我设法通过引用package.json通过HTTP来实现它:

"repositories": [
    {
        "type": "composer",
        "url": "http://localhost/packages.json"
    }
]

所以packages.json文件如下:

{
    "packages": {
        "vendor/my-package": {
            "dev-master": {
                "name": "vendor/my-package",
                "version": "dev-master",
                "source": {
                    "url": [repository URL],
                    "type": "git",
                    "reference": "master"
                }
            }
        }
    }
}

此外,它似乎是一个用于命令提示符的自动运行注册表项干扰了作曲家运行。

请参阅:Requiring a private git Bitbucket repository fails to find valid composer.json

答案 3 :(得分:2)

我知道这有点旧,但对于可能会遇到此问题的人来说,这就是它对我有用的方式。

清除作曲家缓存。

composer clearcache

重新运行令人满意的构建脚本。

答案 4 :(得分:0)

我刚刚将composer.json更新为最新版本,问题就消失了。

答案 5 :(得分:0)

虽然这可能被认为是巫术,但我昨天偶然遇到了这个问题,却遇到了类似的问题(尽管在我的情况下,我运行的是Ubuntu Docker容器,而不是OP,所以我运行Windows),以为我会离开我的想法和解决方案,如果其他任何人会偶然发现这一点。

Composer的Ubuntu回购版本当前为1.6.x(在撰写本文时,我相信Composer的最高版本为1.9.1),并且根据是否运行composer install,我会遇到不同的错误。不同级别的日志记录。如果不进行日志记录,它抱怨说找不到有效的composer.json。有了日志记录,它抱怨说它无法访问该存储库(尽管扫描标签)。

对我来说,解决方案是在全球范围内安装最新版本的Composer,因为Ubuntu回购版本正在使用过时的BitBucket API调用(不建议使用v1)。一旦我更新到较新版本的Composer,安装就可以完美运行。

因此,请检查您的Composer版本,并在可能的情况下安装更新的版本(本地/项目安装也应如此)。