功能建议 ： 可以是用git地址直接安装

[zzhgithub]

这里看到 raven 基本比较类似 node的npm.
但是我觉得应该 支持像npm 一样直接通过 git地址直接安装 之后在后面加上一定的参数。 这样有两个好处。

1. 方便开发者本地测试库的行为。当然这里指的是复杂的调用。当然如果分离模块后进行测试，是不需要 用户在raven install 一次再测试的。 但是实际业务代码中很有可能出现了，写好了觉得没有问题后已经发生问题的情况。（当然 如果有一种 类似maven安装 可以本地mvn install 就安装到本地的方法就更好了。）
2. 不需要用户 过分依赖官方库。这样其实是更加自由的。应该让他们按照raven的标准去开发和使用，但是不用为他们写的“垃圾”代码买单。 我是说：允许他们畅通无阻的使用 raven 官方的库，只要慢慢的审核他们的提交请求就好了。

我看了项目的源码。希望支持这一特性，但是我并不清楚您是否认同上面的观点和特性。所以并没有开始添加功能的工作。我发现这里的代码

中 入参和调用的位置要进行改造。 还有 在package.cs文件中的定义方式和install 参数的方式也要改造。任务是个我不能决策的改动所以来征求你的意见。如果你打算实现那么太好了。期待你的回复。

[guenchi]

这是一个很有意义的提议：

但是存在一些担忧：

Raven是存在一定的系统调用功能的，那么当安装第三方地址的库，也就是说未经过严格审核的代码，会导致一定的安全问题。

这些问题包括但不限于：

Raven官方认为，如果你使用git地址，但并不是官方仓库时，代表你了解其中隐含的安全问题。而你必须自己为这些问题负责。

但不一定每一个Raven的用户，都非常清楚以上的约定。他们其中一些人，比如说一些比较新的用户，默认Raven的安装是安全的。而另一些用户也许在安装时，因为某种情况忽略了这个安全提示。

还有一种更大的可能是，也许使用者严格的审核了导入的代码，但是在后续的更新中，git合并了不安全的代码。同时由于Raven的自动更新机制，这些不安全的代码被无意的导入了。

当库进行嵌套时，这个问题变得愈发严重。

开发者并不一定清楚它的依赖的依赖的依赖...到底引用了一个什么东西，在这种情况下，要求每个库使用者进行严格的代码审核是一项不可能的任务。

即使是NPM，也遭到了黑客的渗透攻击，那么，从git引入库结果可能更糟。

在这个环境下，进行官方的严格代码审核在我看来是很有必要的一件事情。

我没有完全拒绝社区提议的这种方式，但我认为，在未解决我提出的安全问题之前，这个更改还需要探讨。

[zzhgithub]

感谢你的回复：
我想我明白你的意思了。很遗憾我在之前安全上没有深入考虑。

我不了解Raven现在对于提交上来的库的审核进度和具体情况。如果都进行审核我相信也是很大的工作量。所以我还是建议使用一定的折中方案。

1. 保证官方库了的包和他们的依赖都是被审核了的。也就是说官方认可的包都不会在dependencies里出现直接从git地址上的依赖。这样就可以保证官方库的安全纯净。（也就是说在提交到官方库的代码审核时 如果出现了直接依赖git上地址的库直接打回去或者等待它依赖的库被审核通过）
2. 让用户可以使用自己还是可以安装自己的git包。并且保证git包的依赖和官方的库不一样。
3. 一旦用户使用了用git地址的依赖，在install的时候应该给出一个明确的提示。

或者这种方案可以兼容安全和和我说的需求呢？

最后无论如何感谢你在scheme生态建设上提供的帮助。

[guenchi]

感谢你的回复：
我想我明白你的意思了。很遗憾我在之前安全上没有深入考虑。

我不了解Raven现在对于提交上来的库的审核进度和具体情况。如果都进行审核我相信也是很大的工作量。所以我还是建议使用一定的折中方案。

1. 保证官方库了的包和他们的依赖都是被审核了的。也就是说官方认可的包都不会在dependencies里出现直接从git地址上的依赖。这样就可以保证官方库的安全纯净。（也就是说在提交到官方库的代码审核时 如果出现了直接依赖git上地址的库直接打回去或者等待它依赖的库被审核通过）
2. 让用户可以使用自己还是可以安装自己的git包。并且保证git包的依赖和官方的库不一样。
3. 一旦用户使用了用git地址的依赖，在install的时候应该给出一个明确的提示。

或者这种方案可以兼容安全和和我说的需求呢？

最后无论如何感谢你在scheme生态建设上提供的帮助。

我和你的想法差不多：

1. 提供 --url / -u 选项 方便直接从git库地址安装。
2. 当使用这个选项时，检测用户是否使用了root/sudo，如果是，强制中止并提示用户使用非root模式安装。
3. 这个选项与 -g选项不兼容。也就是只能安装到当前文件夹的lib文件下。
4. 当使用这个选项时，用红字警告用户，应在安装前验证源是否含有恶意代码，并需要用户输入 Y/N 的方式才能继续。
5. 此选项下载完成 可以考虑自动makefile 或者不。需要讨论。
6. 在使用此选项时，无法递归的下载依赖的依赖（如果此依赖也是一个git地址）。也就是说，无法自动下载依赖（git地址）。换句话说，所有发布或未发布到官方源的库，它自身的依赖必须是官方源，而不能依赖另一个git地址。

欢迎实现和PR。如果你觉得在如此严苛的限制下，还有必要的话。