3 ms·

C++ does have a standard package manager. It's the system package manager, instead of a language-specific one. Whether that's good or bad is a matter for some d

C++ does have a standard package manager. It's the system package manager, instead of a language-specific one. Whether that's good or bad is a matter for some debate, but it does exist.

BoorishBears 7y ago
> C++ does have a standard package manager. It's the system package manager, instead of a language-specific one. So C++ does not have a standard package manager. Or are we really going full HN and debating the meaning of the word standard? Even if we are... is there a standard system? For that standard system, is there a standard package manager?
- notacoward 7y ago
  You're the only one trying to play with definitions of "standard" here. The system package manager was the standard packaging method for extra functionality on Linux (and other) systems regardless of implementation language before perl/Python/etc. started coming up with their own. You might argue that it's a bad standard, that it doesn't work for more "nimble" languages, whatever, but it is how C++ code is supposed to be packaged and has been for a long time. What C++ doesn't have is an exclusive package manager that can't be used with other languages. Non-exclusivity doesn't make anything less standard. Quite the contrary.
  - BoorishBears 7y ago
    This is not how language works. You don't get to just slice up a sentence and then talk to the parts that suit you "C++ does not have a standard package manager." C++. The language. Does not have a standard package manager. From your own comment: > It's the system package manager, instead of a language-specific one You're literally admitting C++ does not have a package manager right there and then saying it's up to the system to fill in that gap! - This is a seriously mind-numbing conversation because all your replies make it clear you know EXACTLY what they mean, yet you're so focused on being the obligatory contrarian who has to proudly proclaim C++ has been done the way it's done and that's a fine way (and won't go so far as to say it's the correct way because deep down we all know it's not, but will always go right up against that line and pull out the "well it worked for all that C++ code out there" if you push back) and all you kids with your nimble languages can say it's bad but you just don't get it. This is why for my mental sanity I try to refrain from talking about the meta situation of C++. The language, not the system. To be clear.
mikepurvis 7y ago
Sure, but you need to be root to install those, they're not portable, and there's no workspace isolation or build system consistency— yes CMake has bridge methods to work with autotools/pkg-config, but it's all pretty hacky. For a tool that does attempt to do virtualenv-like workspaces for C++ packages, see colcon [1], but there are still a lot of rough edges there— it's an evolution of the catkin multi package build system/tool from the ROS ecosystem, and part of the promise of it is a pluggable mechanism for discovering the packages in your workspace to avoid needing to a patch in a special XML file containing dependency information. [1]: https://colcon.readthedocs.io/ https://colcon.readthedocs.io/

C++ does have a standard package manager. It's the system package manager, instead of a language-specific one. Whether that's good or bad is a matter for some debate, but it does exist.

BoorishBears 7y ago

> C++ does have a standard package manager. It's the system package manager, instead of a language-specific one. So C++ does not have a standard package manager. Or are we really going full HN and debating the meaning of the word standard? Even if we are... is there a standard system? For that standard system, is there a standard package manager?

notacoward 7y ago
You're the only one trying to play with definitions of "standard" here. The system package manager was the standard packaging method for extra functionality on Linux (and other) systems regardless of implementation language before perl/Python/etc. started coming up with their own. You might argue that it's a bad standard, that it doesn't work for more "nimble" languages, whatever, but it is how C++ code is supposed to be packaged and has been for a long time. What C++ doesn't have is an exclusive package manager that can't be used with other languages. Non-exclusivity doesn't make anything less standard. Quite the contrary.
- BoorishBears 7y ago
  This is not how language works. You don't get to just slice up a sentence and then talk to the parts that suit you "C++ does not have a standard package manager." C++. The language. Does not have a standard package manager. From your own comment: > It's the system package manager, instead of a language-specific one You're literally admitting C++ does not have a package manager right there and then saying it's up to the system to fill in that gap! - This is a seriously mind-numbing conversation because all your replies make it clear you know EXACTLY what they mean, yet you're so focused on being the obligatory contrarian who has to proudly proclaim C++ has been done the way it's done and that's a fine way (and won't go so far as to say it's the correct way because deep down we all know it's not, but will always go right up against that line and pull out the "well it worked for all that C++ code out there" if you push back) and all you kids with your nimble languages can say it's bad but you just don't get it. This is why for my mental sanity I try to refrain from talking about the meta situation of C++. The language, not the system. To be clear.

mikepurvis 7y ago

Sure, but you need to be root to install those, they're not portable, and there's no workspace isolation or build system consistency— yes CMake has bridge methods to work with autotools/pkg-config, but it's all pretty hacky. For a tool that does attempt to do virtualenv-like workspaces for C++ packages, see colcon [1], but there are still a lot of rough edges there— it's an evolution of the catkin multi package build system/tool from the ROS ecosystem, and part of the promise of it is a pluggable mechanism for discovering the packages in your workspace to avoid needing to a patch in a special XML file containing dependency information. [1]: https://colcon.readthedocs.io/ https://colcon.readthedocs.io/