Please improve the library and package manager like Npm, Cargo

[sirlordt]

Please implement something like npm, cargo. Is very important!!!!

[davidzchen]

I don't think the project is at the stage of building a package management system yet, since the core syntax is what is currently being worked out, but having an easy way to pull in external Carbon libraries is something we should consider.

The lack of an easy way to import external libraries such as via a standardized package management system has historically been a major pain point for C++, though part of the reason is that there is such a huge variation of build systems used by different C++ codebases.

I think there is a good opportunity to improve this area and create some kind of standardized package management offering for Carbon once the project gets to that stage.

[robiot]

What about the name Fiber for the package manager (from carbon Fiber)?

[davidzchen]

Carbon Fiber is a wonderful name. :)

One possible concern is that it might clash with Google Fiber, but hopefully, that is not enough of a reason against this.

[jonmeow]

To be sure -- infrastructure for package management is explicit in the goals, it's just a ways off.

https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#language-tools-and-ecosystem

[andrewfenn]

Rather than state the obvious that one is needed, I would instead like to say that there needs to be a lot of planning and learning from the mistakes of other package managers. I hope that is done and someone doesn't just start coding their own. A lot of inspiration can be gathered from how for example Debian's package manager works.

When it comes to a package manager and central repository I would recommend all the following should be kept in mind for whatever a first version of a package manager looks like..

• Packages should have explicit rules on how they should be setup so it is less ambiguous when inspecting multiple packages. This is a major problem with c++ which makes build envs a nightmare. Even when using something like CMake that is so much variety in how it can be setup and most of the time this variety has no reason other than to be different. Better to make it consistent and explicit.
• Packages should be cryptographically signed by their package maintainers. If there is a build step where the packaging system will provide both a source package and a binary package to the user then the binary package must also be signed by whatever build system built it. I.E. author submits their source code signed by their key, the build system builds and signs the binary package with their key too. This way if a build system in the future has been attacked all packages built by it can be invalided.
• Personally i would prefer if binary as well as source packages were provided so that faster code deployments can be made without having to completely build all the source code from packages you depend upon. Obviously this would most likely be and optional thing as I am sure there will be a lot of different architectures Carbon would want to target. In debian source, binary and debugging symbols are provided as separate packages. I think that would make sense for a new package manager too.
• There should be a robust mechanism for invalidating old packages
• The packages should be built within a sandboxed environment to avoid malicious packages from affecting your system. Obviously doesn't help if you run the built code but nothing bad should happen to your system for simply downloading a dependency and building it.
• Enforced semantic versioning
• Enforced requirements surrounding what version of the language and architectures the package supports and the ability to download the dependencies to your computer regardless of which version of the language you actually have installed on it at the time.
• Upfront rules regarding control over the packages to avoid authors from pulling all their packages out the central repository simply because they had a hissy fit one day
• Upfront rules regarding name spacing and trademarking to avoid drama down the line
• Protections from off by one character malicious packages when checking namespacing in a central repository
• A way to pre download all your dependent packages into one file to make deployment easy
• There should be an easy way to point away from the central repository maintained by Carbon to a private repository or public mirror. That way you can use the system without needing an internet connection or companies can maintain and enforce what packages are available for use within their ecosystem. It should be easy to setup such a repository without having to use specialised tools to make a repo. I.E. Debian repositories can exist just on an HTTP path which means all you need to know is how to setup a webserver. You don't have to deal with custom software or alternatively even just a file path on your system of a private repository of packages.
• Package maintainers should be asked if their code provides any sort of encryption technology that can not be exported outside of the US so that companies in countries the US has embargoed don't need to be excluded from using the entire public repository of packages

[anton-roos]

What about the name Fiber for the package manager (from carbon Fiber)?

I do like this name. Covalent might also be a cool name, it is how carbon bonds to other elements and to "package" something you are basically "bonding" your code with a package 📦 I think both names are cool.

[Taack]

What about the name Fiber for the package manager (from carbon Fiber)?

I do like this name. Covalent might also be a cool name, it is how carbon bonds to other elements and to "package" something you are basically "bonding" your code with a package package I think both names are cool.

Covalent bonds are not limited to carbon AFAIK :) .. There are so many cool names with Carbon, like diamond, Footballene, graphite, nanotube ...

[MichaelBonnet]

Perhaps "org" or "organ", as Carbon enables organic life to exist. And the code is made up of code "organs".

or something like that.

[MichaelBonnet]

• A way to pre download all your dependent packages into one file to make deployment easy

How close is this proposed requirement to something like conda environments for Python?

[anton-roos]

What about the name Fiber for the package manager (from carbon Fiber)?

I do like this name. Covalent might also be a cool name, it is how carbon bonds to other elements and to "package" something you are basically "bonding" your code with a package package I think both names are cool.

Covalent bonds are not limited to carbon AFAIK :) .. There are so many cool names with Carbon, like diamond, Footballene, graphite, nanotube ...

I like Diamond and Nanotube.

[chandlerc]

Not that I don't enjoy all the fun names, but I don't think its really useful to have an issue tracking a package manager this early in the project. As Jon mentioned, it's tracked in our goals. Closing this as not-planned-right-now-but-definitely-in-the-future.