g632104866

@yijiangchengming 感谢支持，我记得你之前提过 Rust 和 APT 的，现在 Rust 的已经支持了，APT 在规划中了，但是，但是 [精美的 web-ui 界面] ，这个对后端佬有点挑战了。我自认为比 Nexus 要好看，哈哈，另外欢迎提供参考案例

@a1428265354 我已经评估过你提的问题，确认是一个理解问题，而且权限语义这块是特意和 Nexus 对齐的，后续会加强文档方面的建设，避免理解歧义。再次感谢你的审查。

@lanshouhuidong 感谢老用户支持

@a1428265354 看到了，进回收站了。感谢反馈，这个问题，可能是已知的，为了对齐 Nexus 做的取舍。我会好好评估下，再次感谢你的反馈

@a1428265354 嗨咯，我查收了邮箱列表，没有新增的邮件

@catcalse 是的，支持无缝迁移 Nexus 到 kkRepo 。包括账号和权限。就是说，从 Nexus 迁移到 kkRepo 后，你用之前的账号密码可以在 kkRepo 登录。之前的 CI 和 Maven Setting 文件都不需要更改配置。Path

@pc10201 感谢补充，你说的这个项目，我们在遇到 Nexus 限制的时候，调研过，为什么没直接用，而是开发了一个新的，有以下原因：1 、artifact-keeper 不是纯开源的（生称代码开源），他也有商业计划，类似 Nexus 一样 。2 、他依赖了 OpenSearch 做做全文索引，相当于又需要多维护一个组件 3 、最重要一点，他支持 Nexus 支持的仓库类型，在权限、Path 上不兼容，意味着从 Nexus 迁移到 artifact-keeper ，不仅需要解决私有包的迁移，大量的客户端、CI 都需要一起跟着调整。 这个是不可接收的。 而 kkRepo 的定位，很明确，简单已部署、多副本高可用。一键迁移 Nexus ，而客户端 、CI 都不需要改了。连 Nexus 的用户+权限都可以整套搬迁到 kkRepo ，这个就是 kkRepo 区别与其他制品仓库的意义。

@moyuge 非常赞，纯代理路线和 kkRepo 稍微有点不一样

@mMartin conda 在实施的路线图了，现在已经有 pypi 了 。现在底座已经打好了，目标是最终支持所有的仓库类型