Twitter | Search | |
mcc
The programming language, the build system, the package manager, and the version control system should all be the same piece of software I will accept the programming language being split off into its own thing but the other three there's just no excuse
Reply Retweet Like More
Timonic 💜 May 13
Replying to @mcclure111
I would love this to be the case would make my job so much easier!
Reply Retweet Like
mcc May 13
Replying to @mcclure111
Like what I long for so badly is to be able to check out a private copy of a library's package within a project, modify it in-tree, then push the results back to version control so I can open a PR on the original project.
Reply Retweet Like
june May 13
Replying to @mcclure111
It's such a sad state of affairs that our concept of Operating System hasn't matured to this level yet. We're still stuck with "well at least occasionally you can guess that your process will run"
Reply Retweet Like
mcc May 13
Replying to @mcclure111
This is because I often want to fix or change something that's in a sub-dependency, but making that change would be easiest if I'm testing it in my super-project. But if a library's vended from the package manager half the time you can't even *build* a custom version w/o breakage
Reply Retweet Like
Jaa͑r Ḥewer May 13
Replying to @mcclure111
The first 2 are combined in rust. I would also add the testing framework.
Reply Retweet Like
Tim Panton May 13
Replying to @mcclure111
Whilst I find maven a bit of a bore to use, it does seem to have that bit roughly right. - Untill you hit a native/JNI dependency - then things fall apart.
Reply Retweet Like
mcc May 13
Replying to @steely_glint
Huh. Maybe I should research that.
Reply Retweet Like
Tim Panton May 13
Replying to @mcclure111
mvn is very java/JVM centric I’m afraid, but perhaps some ideas worth transporting elsewhere.
Reply Retweet Like
Ryan ✨ Pavlik May 13
Replying to @mcclure111
That's a pretty interesting thesis. The general fascination with tools means it's unlikely to take hold, but I see the appeal. (I use git submodules for a reason: they're far from perfect but at least I can slurp in dependencies and modify them in tree)
Reply Retweet Like
Ryan ✨ Pavlik May 13
Replying to @mcclure111
And well, I mostly use c++, which doesn't really have a package manager (that's widely used, anyway), so my bar of expectations is pretty low.
Reply Retweet Like
Scott Mc🐝 May 13
Replying to @mcclure111
Version control is already awful. Learning a slightly different, bad git clone for each language sounds nightmarish
Reply Retweet Like
mcc May 13
Replying to @mscottmcbee
I don't use git so I don't think of version control as particularly awful
Reply Retweet Like
Scott Mc🐝 May 13
Replying to @mcclure111
I know it doesn't have to be, but the community seems to think only git and svn exist. Most of my coworkers haven't even heard of Mercurial. I imagine most tooling would cater to that
Reply Retweet Like
russell May 13
Replying to @mcclure111
I do this regularly in Rust with Cargo's [patch] and it works great:
Reply Retweet Like
mcc May 13
Replying to @rpavlik
git submodules are very close to what i want but they're heaviweight for certain things and they're not very flexible
Reply Retweet Like
graham something May 13
Replying to @mcclure111
Yes! Direct link to PR's, issues, working forks. I wished for a git-submodule orientated package manager for unity, but I don't think it's going that way. (This is my current system for various c/++/web/unity setups over many projects, even if they're all internal)
Reply Retweet Like
Aeva Aeva Aeva Aeva Aeva Aeva Aeva Aeva Aeva Aeva May 13
Replying to @mcclure111
*finger on the monkey paw curls* git-based programming language, git-based build system
Reply Retweet Like
Nathan Reed May 13
Replying to @mcclure111
Lang/build/package makes sense to me…but version control feels like a separate responsibility. (Like…what do you do with a project/repo that uses multiple languages?) Agree it should be easy to switch between packaged and local versions of deps though.
Reply Retweet Like