tt作曲家简谱打谱软件_作曲家全球需求被认为有害吗？

tt作曲家简谱打谱软件

We’ve discussed Composer best practices before, and I’ve always advocated using composer global require when installing packages that can be used across several projects – particularly command line tools. Then, the other day, I ran into this discussion.

之前 ，我们已经讨论过Composer的最佳实践，并且我一直主张在安装可用于多个项目的软件包时，尤其是命令行工具时，使用composer global require 。 然后，前一天，我遇到了这个讨论 。

The short of it is – the majority of people now seem to feel like global require is bad practice, unless the globally installed package has zero dependencies. Technically, this makes sense when one is using a single environment for all their projects, but as I commented in that discussion, when using a VM per project or a properly isolated environment like Docker or the like, then this problem is moot and global literally cannot do harm.

简而言之-除非全局安装的软件包具有零依赖关系，否则大多数人现在似乎觉得global require是一种不好的做法。 从技术上讲，当所有项目都使用一个环境时，这是有道理的，但是正如我在该讨论中所评论的那样，当每个项目使用VM或适当隔离的环境(例如Docker等)时，这个问题实际上就不存在并且是global不会造成伤害。

The OP’s suggested solution to this problem is:

OP针对此问题的建议解决方案是：

As an alternative, users should use composer require to install each commandline tool to its own local project, and manage their $PATH or binaries manually (e.g. by creating symlinks from a bin directory already in the $PATH).

或者，用户应使用composer require将每个命令行工具安装到其自己的本地项目中，并手动管理其$PATH或二进制文件(例如，通过从$PATH已经存在的bin目录创建符号链接)。

This, to me, is an entirely unacceptable complication. Composer has been the pride of PHP in how easy it was to use and how newbie-friendly it made package management – local or global. Having to symlink things around (especially taking into account non-symlink OSs like Windows) would add tedium. The OP then goes further to suggest a change to how the global command works:

对我来说，这是完全不可接受的并发症。 Composer一直以PHP引以为豪，因为它易于使用，并且使新手友好地使软件包管理(本地或全局)成为可能。 必须对周围的事物进行符号链接(特别是考虑到非符号链接的操作系统，例如Windows)会增加乏味。 然后，OP进一步建议更改global命令的工作方式：

a “global” but isolated project could be installed to ~/.composer/global/[something]; its vendor and bin directories would appear in their usual locations, and the contents of the ~/.composer/global/[something]/bin directory could be mirrored (via symlink) in ~/.composer/vendor/bin or, perhaps a better option would be simply ~/.composer/bin. There are various ways that the string [something] could be chosen; the most straightforward would be simply org/project (although this means that long paths such as ~/.composer/global/org/project/vendor/org/project would exist).

可以将一个“全局”但隔离的项目安装到〜/ .composer / global / [something]； 它的供应商和bin目录将出现在其通常位置，并且〜/ .composer / global / [something] / bin目录的内容可以(通过符号链接)镜像到〜/ .composer / vendor / bin或更好的选择只是〜/ .composer / bin。 可以选择字符串[something]的方式多种多样。 最直接的方法就是org / project(尽管这意味着存在〜/ .composer / global / org / project / vendor / org / project之类的长路径)。

I completely agree with this approach, and it seems like the best of both worlds. Obviously, it might cause some backwards-compatibility headaches, but that’s not to say it can’t happen in version 2.0 of Composer. Taylor Otwell echoes this sentiment a bit further below:

我完全同意这种方法，而且似乎两全其美。 显然，这可能会引起一些向后兼容的麻烦，但这并不是说它不能在Composer的2.0版中发生。 泰勒·奥特威尔(Taylor Otwell)在下面进一步回应了这一观点：

Totally agree. It would be amazing to have each composer global installed package installed into its own isolated directory with its own isolated dependencies instead of possibly conflicting with other globally installed packages.

完全同意。 将每个作曲家全局安装的软件包安装到具有自己独立的依赖关系的自己的独立目录中，而不可能与其他全局安装的软件包发生冲突，真是太神奇了。

Following all this, in true open-sourcery spirit, the OP then built the alternative global implementation as a separate tool: cgr. Let’s take a look at how it works.

遵循所有这些原则，OP秉承真正的开源精神，然后将替代global实现构建为单独的工具： cgr 。 让我们看看它是如何工作的。

CGR – Composer Global需要替代方案 (CGR – Composer Global Require Alternative)

I’ll be executing all the below commands on a Homestead Improved instance

我将在Homestead Improvementd实例上执行以下所有命令

To start using CGR, we install it as a global package.

要开始使用CGR，我们将其安装为全局软件包 。

composer global require consolidation/cgr

If the bin folder of your Composer isn’t in the PATH variable, add it:

如果您的Composer的bin文件夹不在PATH变量中，请添加它：

echo "export PATH=\$PATH:\$HOME/.composer/vendor/bin/" >> ~/.bashrc
echo "export CGR_BIN_DIR=\$HOME/.composer/vendor/bin" >> ~/.bashrc
source ~/.bashrc

The above commands extend the $PATH env. variable with the route to Composer’s global bin directory (the default location on Homestead Improved – yours may vary). The second command configures the bin directory for cgr to use, while the third loads these changes. These will also be auto-loaded every time you run the terminal interface as this user (in my case, Vagrant via vagrant ssh).

上面的命令扩展了$PATH env。 带有到Composer全局bin目录的路由的变量( Homestead改良版的默认位置–您的位置可能有所不同)。 第二条命令配置供cgr使用的bin目录，而第三条命令加载这些更改。 每次您以该用户身份运行终端界面时，这些文件也会自动加载(在我的情况下，是通过vagrant ssh Vagrant)。

CGR should then be accessible by just running cgr, and should output Composer’s general help file.

然后，只需运行cgr就可以访问CGR，并且应该输出Composer的常规帮助文件。

正确安装全局Composer软件包 (Installing a global Composer package the right way)

cgr phpunit/phpunit

On Homestead Improved, there is a useful alias configured where typing phpunit expands into vendor/bin/phpunit which comes in handy when phpunit is installed per-project, so it can be run from the root folder. To test the global installation of PhpUnit, we need to remove this alias first (in ~/.bash_aliases comment the appropriate line) and then exit the shell and re-enter, so the aliases reload. Then, running this newly globally installed PhpUnit with version output should produce something like:

在改进的Homestead上 ，配置了一个有用的别名，其中将phpunit键入扩展为vendor/bin/phpunit ，这在按项目安装phpunit时非常方便，因此可以从根文件夹运行。 要测试PhpUnit的全局安装，我们需要先删除此别名(在~/.bash_aliases注释相应的行)，然后退出外壳程序并重新输入，以便重新加载别名。 然后，使用版本输出运行此新全局安装的PhpUnit应该会产生以下结果：

vagrant@homestead:~$ phpunit --version
PHPUnit 5.4.2 by Sebastian Bergmann and contributors.

Now let’s try to install two incompatible packages.

现在，让我们尝试安装两个不兼容的软件包。

cgr laravel/installer
cgr wp-cli/wp-cli

Sure enough, they both get installed fine. Let’s check if they work.

果然，它们都安装良好。 让我们检查一下它们是否起作用。

vagrant@homestead:~$ wp --version
WP-CLI 0.23.1
vagrant@homestead:~$ laravel --version
Laravel Installer version 1.3.2

All good! Global packages that previously conflicted due to mismatches in dependencies can now co-exist side by side and be used OS-wide without a hitch!

都好！ 以前由于依赖关系不匹配而冲突的全局软件包现在可以并存共存，并且可以在整个操作系统范围内轻松使用！

该工具应该做什么/不能做什么？ (What should/can the tool NOT do?)

In some cases, you may want to install Composer plugins. As the limitations part states, due to CGR installing each global package into its own folder with its own dependency tree, these would not be globally available across all global projects then. As such, if you want to install plugins that alter composer’s general behavior, you should still use composer global require instead of cgr. CGR itself is one such plugin, for example.

在某些情况下，您可能需要安装Composer插件。 正如限制部分所指出的那样 ，由于CGR将每个全局程序包都安装到具有自己的依赖关系树的自己的文件夹中，因此，它们将不会在所有全局项目中全局可用。 因此，如果要安装可改变作曲家常规行为的插件，则仍应使用composer global require而不是cgr 。 例如，CGR本身就是这样一种插件。

下一步是什么？ (What’s next?)

Test, test, test! If you’re a frequent user of the global require command, I urge you to test this new tool and give Greg Anderson some feedback on how well it satisfies your global needs and what could be improved, if anything.

测试，测试，测试！ 如果您经常使用global require命令，我敦促您测试此新工具，并向Greg Anderson提供一些反馈 ，说明该工具满足您的全局需求的程度以及可以改进的地方(如有)。

Note that this tool is still just a proof-of-concept, and the implementation may or may not be renamed, repackaged, implemented into Composer’s core eventually, etc. In other words, use it as much as possible, but don’t grow to depend on it too much just yet.

请注意，此工具仍只是概念验证，并且实现可能会或不会重命名，重新打包，最终实现到Composer的内核中，等等。换句话说，请尽可能多地使用它，但不要增加太过依赖它了。

While your global packages are installing, why not tell us how you feel about composer global require? Is it as harmful as many seem to now think, or is it just a matter of being careful and having isolated development environments? Something else? Chime in below!

在安装全局软件包时，为什么不告诉我们您对composer global require ？ 它是否像许多人现在认为的那样有害，还是仅仅是保持谨慎并拥有孤立的开发环境？ 还有吗 钟声在下面！

翻译自: https://www.sitepoint.com/composer-global-require-considered-harmful/

tt作曲家简谱打谱软件