Giters

petemcw / dotfiles

💻 A collection of config files that bring flavor to my digital world

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

What is your general plan for this repo?

lfilho opened this issue · comments

commented

Hi @petemcw thanks for this repo. I was researching new dotfiles repos to base a new one for me when I found yours, @holman's, and @alrra's to be my favorite ones (besides my current one, a @skwp's fork).

So I have some question about what are your plans to this repo and how to you see it differing form https://github.com/alrra/dotfiles to see how would I best direct my contributions: here or there, forking away or contributing to upstream, etc...

So if you have the time to answer that, that would be much appreciated. Thanks in advance and count on me to help you out.

Testing

I like your approach of using docker to test stuff out. But I see Alrra does it differently (see the test/ folder and Travis CI's builds. What are your plans?

Features

In terms of features, it seems to me that this repo differs from Alrra's on being zsh instead of bash. Correct? Is there any other major differences?

Topical structure

I really really like Holman's idea of topical organization. Also, I think it makes contributions and new additions, removals or quick experiments a breeze (and safer). And it's easier for people (including our future selves) to navigate, find stuff and maintain it.

So what do you think? Do see this topical approach happening here?

Easy customizations & upstream contributions

I think the reason we have oh so many dotfiles repo is because we surely will need to change stuff to our own needs and hence we eventually need to fork a repo. Then the original repo maybe be left without so many contributions and fixes from the community and the forked repo may miss out on newer stuff (and fixes) on the upstream repo.

So I was thinking of a approach that would help alleviate those problems. It presumes the above topical structure is in place. We could think of a custom file (git ignored) containing a "blacklist" or "skip-list" that would be read at installation/update time and not install those modules. Example: the repo could have the folders java/, node/, go/, etc. But I may not care for java and node at the moment, so I could edit this, say, ~/.dotfiles/custom-topics.zsh and blacklist java and node there. If in the future I'm interested in those, I just remove them from the blacklist and run the update process.

I would like to try the same approach for VIM plugins as well (so its startup, execution and eventual debugging get faster).

What do you think?

Oh-my-zsh

Have you considered Prezto instead of oh-my-zsh? Basically it's a complete, saner, rewrite of OMZ with more stuff. There's plenty of articles explaining the differences in the depth out there if we google it, so I won't spam you with links here.

But then again I don't have strong feelings about this.

VIM

I was willing to try NeoVim out too... Thoughts?

Thanks again!

commented

Thanks, @lfilho, for the kind words but much of my stuff is based on so many other talented folks. That said I've learned and benefited so much from the open-source community that it only seems right to put my ideas out there as well.

I'll do my best to address your questions and points but please forgive me if I miss anything. You have asked some great questions. Honestly, I haven't spent much time thinking about the future of my current dotfiles repo. Like many others, it ends up morphing over time as my abilities, interests, and preferences change.

The overarching themes I kept in mind when building the current iteration of my repo were:

  • I wanted a version of an installation assistant that would guide the user through setup
  • I wanted my dotfiles to not only customize my CLI environment but also participate in getting a new MacOS installation ready to use
    • Hence the inclusion of fonts, preferences, and brew cask calls
  • I wanted things to generally work on both MacOS and Linux
  • I wanted to be able to test my repo during development using Docker

Just to get it out there, I'm positive that @alrra updates his repository much more frequently than I do. My track record has me using what I have until I'm ready for a new experiment and then I change everything up -- not exactly the best situation for contributors. That said I'm always open to suggestions.

Testing

I love Docker and decided to have it help me out with my current dotfiles implementation. It's great to be able to make big changes and see how they work inside a container rather than on my live system. @alrra is primarily using a third-party script to check shell script syntax. I used a similar method while building this but it would be cool to automate it more. Outside of syntax checking, I'm not sure if there is a better way to test dotfiles. Have you run across any other testing implementations?

Features

The biggest difference is that I'm using zsh rather than bash. Another difference is that I carried over a habit of suffixing items with .symlink or .copy. It has been helpful to allow a more free-form organizational structure while maintaining the ability to link items easily.

Topical

I also like @holman's organizational ideas. An older incarnation of my repo was based on his. At the time I found that many things didn't fit "nicely" in a single topic so I moved away from that idea. It was a while ago and I've removed a lot of cruft from my repo since then so it would be worth looking into again. I agree it would make contributions and experiments easier.

Contributions

With the repo installation/update process, I am trying to achieve a simplified version of what you're suggesting. Two main issues to be considered here are:

  • I want the "excluded topics" to not be processed via a shell script every time a shell is launched; I've had a new shell open in 2+ seconds before because so much stuff was evaluated
  • I personally want my dotfiles to be cloneable, installable, and ready to go; using an ignored "blacklist" file would mean we have to remember what goes in it on a new machine or retrieve from a backup

I'm sure there is a clever way around both issues that can still achieve the goal of easy customizations/contributions but I haven't thought it yet.

Oh-my-zsh

I've only looked at Pretzo briefly. From what you said it sounds like it might be a great option but I haven't had much trouble with Oh-my-zsh so I never bothered to look elsewhere.

Vim

I haven't really considered NeoVim much but that is mostly because I don't code in Vim. I like to have some decent customizations but I'm mostly in Vim on servers and doing basic editing rather than using it as a full on IDE. It looks cool though, have you used it much?

commented

Hey man. Sorry for the delay. Was travelling on holidays.

Testing

No, I haven't come across different testing implementations. I was thinking (not sure if it's even possible): to use Docker to automate testing. It would probably be a smoke-test (e.g. checking if the shell was correctly configured and is responsive as expected...). That possibly combined with the syntax checking...

Topical

Yeah, I agree it's not perfect (as nothing is) but atm is the best one imho...

Contributions / installation

  • Re: your first topic - Yeah, I agree about the loading times. But in this case I think it would be a considerable overhead: "if folder name equals ruby or node or java, don't load them, otherwise load it". It would be just a few boolean checks in a small list (our "topics" list). So I think that overhead could be ignored...
  • Re: Also agree with the "plug and play" approach. Then as for the blacklist we could simply provide an example file, with a few examples commented out. That would hopefully solve the problem you're concerned about it. This blacklist file would also, of course, be optional. So if someone would like to have the fully featured repo (all topics loaded), they could.

Oh-my-zsh

Fair enough. Definitely both are great. I just believe Prezto has more sane defaults, more libs and is easier to extend / read.

Vim

Ah ok. I thought vim was your main editor (as it's mine). I haven't fiddle much with NeoVim yet. As of now it's pretty much paired with vim. Its golden days are still to come I think - due its new architecture and saner codebase more contributions and more powerful plugins will come.

Let me know if I can help somehow