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
Winters 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
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 Poltergeist 👻🎶 May 13
Replying to @mcclure111
*finger on the monkey paw curls* git-based programming language, git-based build system
Reply Retweet Like
Nathan Bleed 💉 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
mcc May 13
Replying to @Reedbeta
all programming languages should merge
Reply Retweet Like