initiate new projects with version control

[dpgraham4401]

Description of request

I didn't see an issue related to this, so i figured I'd open this one up since it's one of my favorite cargo defaults.

Title is pretty self explanatory. Just like cargo, by default Huak would initiate a git repo with a new project.

Could probably get by with git without someone else even mentioning other VCSs for a long time.

[cnpryer]

Yea I think this is a good idea, though to be honest I've never used that feature myself (at least intentionally). I usually just start with gh cli.

But I'm pretty married to GitHub.

[dpgraham4401]

GH is king but wouldn't want to be unnecessarily inflexible.

probably would have to pull in rust's bindings for libgit2
https://crates.io/crates/git2

[cnpryer]

Looks good. Curious what your thoughts are on being dependency heavy. In an ideal world I imagine it'd be nicer to have a package manager with a lighter dependency tree. I really haven't put much thought into it though, so I'm mainly just curious of your thoughts if you have any.

[dpgraham4401]

Well this answer got out of control haha. It's a good question.

TLDR version;

I think, especially during this early phase, getting something up and running that's good for the user should probably be Huak's first, second, and third priority. If we're judicious about which dependencies huak pulls in, build up a test suite that we're confident in, and maintain good developer docs for future reference, we'll be golden.

Unwarranted rant version;

IMO Rust is weird in this regard. My thought process is predicated on the premise that I believe the Rust ecosystem didn't adopt the "Roll Your Own" mentality that's present in other lower-level languages, and kinda takes a page from JavaScript's book of "Don't Reinvent the Wheel" (in addition to the "lets just keep cramming more features into the language core" mentality, but I digress).

This next part is going to sound a little gate-keepy. I think a "Don't Reinvent the Wheel' ecosystem is good, it makes languages more accessible, and allows everyone (and newcomers, myself included) do awesome things. But it can be a double edged sword, especially when developers/newcomers aren't afraid to do things like break a little backwards compatibility without updating the release's major version. We've all done it, myself included.

With that said, I don't think we should be afraid of dependencies, we just gotta be mindful. Weigh the pros and cons. Asking ourselves "Will this make maintaining Huak easier or potentially more difficult over time?" is always a good litmus test.

Also tests that we're confident in. Like, check out Cargo's mile long dependency list, but also dat test suite doh. We can do something similar so, when dependabot suggests an update, we know some jabroni didn't just sneak in a breaking changes without updating the major version.

Probably best not to worry too much at this point. Size wise, the pypi wheel is clocking in at less than a couple MB download size (probs more on mac) and it's blazing fast. The fact that you're even asking that question this early on is a good sign IMO, glad you're thinking about that kinda stuff.

[cnpryer]

Thanks for this. Not unwarranted at all. This is what I was hoping for 🙌.

Makes sense. My thought process was just that I don't want to alienate any potential users. So I was thinking a package manager with a light dependency list would attract everyone versus one with a heavy list would attract a subset. But you made some great points.

[LoipesMas]

What are the arguments against just having a .git folder ready and pasting it to new projects? Compressed it should take up a few KB.

[dpgraham4401]

hey @LoipesMas, that's some out of the box thinkin'

I think that might be a ok solution if we just wanted to initiate a git repo and that was all that huak ever wanted to do. But my big qualm with it would be the lack of flexibility or the ability to be expanded on. Like if we decided we wanted do more than just initiate a blank repo.

[LoipesMas]

Yea, flexibility is probably the main issue with that approach. But I'm pretty sure we could do some simple operations on files directly without too much hustle. But we could leave solving that problem for when we get there.

Alternatively we could call git command directly, because if the user wants a git repo, they probably have git installed. And fail or give a warning if git is not found.
But that's also a bit hacky

[cnpryer]

I'm not opposed to hacky methods for the PoC if it allows us to ship features in an mvp-style state. I don't know how realistic this is, but after the PoC I'd really like to steer development using feedback from people who can engage with the project by tinkering with it.

This is why I'm okay with wrapping pip for a bunch of stuff for the PoC.

A package manager can have a lot of scope, so I think this is the best strategy.

With that said, nothing is set in stone. So feel free to lmk if you disagree.

[LoipesMas]

I agree that for now we should focus on getting core features working and worry about details and potential new features later.

[dpgraham4401]

If we're interested in the quickest way to get up and running, we should probably just use the git2 crate anyways. It's like 3 lines to initiate a repo, then we circumvents the hacky compressed .git repo and managing git configs. Not to mention, much more flexible, scalable, and maintainable.

[cnpryer]

That sounds like a deal 👀

[dpgraham4401]

@cnpryer @LoipesMas

What are y'all's thoughts on defaults. Should huak create new projects with git repos by default, or should it be something that the user needs to opt in to?

As usual, I think we should follow Cargo's example.

[LoipesMas]

Definitely create with git by default. Can't see why someone would not want that

[cnpryer]

Yea I do think we can take an opinionated stance here. I imagine if someone wasn't going to use a git initialized project they'd either (a) use some other vcs or (b) not use any vcs at all. for the first scenario they can opt-out manually. for the second they can just ignore it altogether.

[dpgraham4401]

@cnpryer please assign this to me 😁

[dpgraham4401]

I'm going to un-assign myself, there's some other items i'd like to work on I think are higher priority.

@LoipesMas Are you interested? If not, I'll come back to this later, no pressure.

[LoipesMas]

Sure! I've been looking for something to do and after making activate command this should be fairly simple(nvm, I thought that's about run command. Should be simple anyways)