Make it possible to configure clog via .clog file about clog-cli HOT 35 CLOSED

What about have two types of configs? Like a system-wide one to set some basic defaults under ~/.config/clog/clogrc and .clogrc for repository specific ones. Btw, I prefer .clogrc with the rc on the end because it's de facto to signfiy it's a config file. Thoughts?

from clog-cli.

Not that there's a massive list of options right now to justify having a system wide config file, but I was thinking ahead in case there's a lot more options in the future (like I have some ideas for too).

from clog-cli.

This would probably be pretty simple with something like toml-rs

from clog-cli.

I'd say a system wide config is nice to have and I wouldn't vote against it. But as you say, we don't have a massive list of parameters (yet) so a local one is what I care about at the moment.

Regarding the naming, I'm also fine with .clogrc.

from clog-cli.

Cool, I think local is just fine for now. :)

And I agree with Kevin about using toml, but at the same time I don't really mind whatever the format either.

from clog-cli.

Ok, cool. Anyone feels like working on that?

from clog-cli.

I would! But I can't! :(

Sorry I can only help with comments for now. If I can make time, hopefully sometime soon, I will give a go at actual contributions, because I do have a few ideas on how to improve clog a bit. But unfortunately no time to focus on this right now. I know the codebase is very small (for now), but I still consider myself a newbie with rust itself, which I want to fix first.

from clog-cli.

No worries, and yep the code base is very small and more or less a direct port from JavaScript to Rust. So it's a good code base to learn Rust ;)

from clog-cli.

I may have some time this weekend to play around with it, but no promises :P I don't want to stop anyone else from working the issue. If I make it to a usable or close state I'll put in a PR.

from clog-cli.

sounds good 👍

from clog-cli.

I started to play with this again today (A little later than the weekend...sorry :P) using toml-rs, but I ran into some moral (?) issues.

If you specify a from or a to in this .clog file, that's somewhat silly as those will change with each iteration. Same thing with setversion and settitle which only leaves from-latest-tag and repository

So I started with a toml file like so

[clog]
repository = "https://github.com/thoughtram/clog"
from-latest-tag = true

Then I started thinking, "why have a toml file with just these two entries?" You cold just make repository default to whatever the current git directory the user is in (which I believe it already does?), and from-latest-tag be the default unless a --from option is used. This kind of negates the need for a .clog file at this point in time. If more options are added later, it may become useful, but I'm not so sure right now. I thought I'd ask you @cburgdorf before continuing on...

On a different off topic note, I started using clog for the changelog in clap and love it...so awesome work! ;)

from clog-cli.

Yeah I was thinking about this. If understand what you meant, why not just grab this information from the .git/config of the local repository, you know, assuming clog is run from a directory somewhere within the repository (which I think it has to right?). Like couldn't we just default to using the origin remote, and have the .clog file for if they want to use a different remote, or a custom value.

Also, scrap the rc from the name in my opinion if you're going to use toml anyway, just make it .clog.toml so that it plays nice with editors who use the extension as preliminary identification for filetype.

from clog-cli.

Great finding @kbknapp! I agree that we could just use sensible defaults for --from-latest-tag and --repository to lower the need for a .clog(rc) file.

I'd agree with @vyp that we should pick the origin from the .git/config file of the repository that clog operates on. If however, the origin remote isn't what the user wants he could just use the --repository parameter to overwrite it as we do today.

The only problem I see is that we probably need to do some parsing/processing with the string that we get from the .git/config file.

For instance mine currently points to https://github.com/thoughtram/clog.git which means we at least would have to cut of the .git suffix. But it could also be an ssh url which means we would have to post process even more.

from clog-cli.

On a different off topic note, I started using clog for the changelog in clap and love it...so awesome work! ;)

Super cool, that you started using it for clap. I'll introduce it for nickel.rs, too as soon as we bring nickel to crates.io :)

I'd really like to spread the usage even more. It would be super cool if we can get it distributed via package managers such as homebrew. Also having windows binaries is on my wishlist but unfortunately cross compiling isn't one of Rusts strength so far :/

from clog-cli.

For instance mine currently points to https://github.com/thoughtram/clog.git which means we at least would have to cut of the .git suffix. But it could also be an ssh url which means we would have to post process even more.

True, hadn't thought of that. If it gets too complicated, you could take the simple route and promote the usage of parameters/config file instead of trying to support every case.

Is the repository parameter only used for the links in the changelog, or is it used for other things too?

from clog-cli.

@cburgdorf Although I haven't done it before, I could look at submitting an Arch AUR package for clog I'm sure that wouldn't be too hard. Of course, that only takes care of Arch users but that's also what I'm familiar with.

For Mac,I have a MacBook that I [almost] never use, so I'm not too familiar with homebrew.

Not to derail too much, as this could go in #12 but as for Windows...that's a whole other beast. I've got some windows machines, so compiling a binary shouldn't be too difficult, but the package management system there is super foreign to me (chocolatey?).

from clog-cli.

@kbknapp I actually just made an Arch AUR PKGBUILD for clog. Except the problem is I'm waiting for #21 to be accepted, because otherwise I don't want to submit a package which doesn't compile.

from clog-cli.

@vyp awesome! I would imagine a clog-nightly-git package or similiar would allow you use Rust nightly as a make-dep, right? Although...after saying that out loud I'm not sure that'd be a great idea as the installee would then have to download a ~160mb Rust install if they didn't already have it...Just thinking out loud.

Edit: which I guess isn't any different from having a clog-git package and requiring stable Rust :P

from clog-cli.

@vyp #21 is merged and published as part of 0.3.2

from clog-cli.

Cool, submitted an AUR package for arch linux: https://aur.archlinux.org/packages/clog-git/.

from clog-cli.

Super cool! Does it mean it's available on arch linux from now on or does it need to go through some review/whatever process first?

from clog-cli.

@kbknapp For some reason, I didn't see your comment before I submitted the package (it didn't show up), all I've done is named it clog-git requiring just rust. It works with rust-nightly-bin because rust-nightly-bin provides rust (in the PKGBUILD). I'm not sure about your setup, does the AUR package work for you? (Without it complaining about unmet dependencies?) However, once arch gets rust-beta on official, I think most of these issues would go away.

@cburgdorf

Does it mean it's available on arch linux from now on

It does! However, it does NOT go through any review process. I think I should expand here just to clarify about a bit of how Arch linux in particular works (this does not necessarily apply to other linux systems).

Arch has 'official' repositories. If you've ever used linux, this is your usual official repositories where you'd expect to find a lot of the basic and popular FOSS software (e.g. system utilities, libreoffice etc.). However, Arch linux does not have that many developers/manpower, so supporting every package ever made (and made available on the internet as open source software), is out of the question.

I think the only distribution which could even challenge to do that is Debian, but I'm not sure.

So what Arch did to help this issue of a lot of software not being available (through official channels) is create the 'Arch User Repository', in short 'AUR'. Basically, ANYONE can upload a 'package' here, and then Arch users can then download these 'packages' and the 'package' can be used straight away (as long as the 'package' is created properly). They DO NOT go through any review process.

What this of course means is, the 'package' can easily be malicious or disingenous, since ANYONE can submit it, not necessarily the creator of the original software itself. However, I quote 'package' here because it is not a package that is being uploaded in the normal sense of the word (i.e. it's not the .exe or .dmg equivalent of linux). It is simply (in most cases) a text file named PKGBUILD which contains instructions to install the original software. This is usually either downloading a binary from the original source, or downloading the source code from the original source, and then compiling it from source, before it can be installed. (On the aur clog page I linked above, on the right there is a "view PKGBUILD" link, to see the one I made for clog.)

So by 'submit', all I really mean is upload to this user-controlled repository which has no oversight. (The arch project strongly discourages using many AUR packages because of this.) There is no review process. However, very popular AUR packages do have a chance to eventually land up in official channels, where of course they will be reviewed and everything.

Ugh, sorry for so many words. I just thought it'd help to explain this because it is your software that is ultimately being made more easily available on a platform, but without your knowledge of how it really works, i.e. whether you can endorse (by linking to it) or not.

from clog-cli.

Thanks for the great writeup. Looking at the receipt it seems it will always install the latest version right?

from clog-cli.

I'm by no means an expert on this, but to be more specific, what would happen (in essence) is I would download this PKGBUILD. Run a command called makepkg (which is usually only found in arch linux) to make the package, i.e. clog, and then I have the clog command available to run. The PKGBUILD syntax is only Bash shell, nothing fancy.

There's three main sections to my pkgbuild, the metadata, the build() function, and the package() function. The metadata is obvious, at the start. The build function is what makepkg uses to compile the software. (It's usually not needed for packages that do not compile from source, but rather download a binary instead.) You can see cargo build --release here.

The package function simply means the (binary) file at target/release/clog will be copied to the system's /usr/bin directory to install the package. (Because I believe rust binaries are self contained?)

To answer the question, yes, because it is a git package. I'm not 100% sure, but if the source specifies a git protocol, makepkg will clone from the git url provided (see the source variable) to get the source code. And I don't do any git checkout, so it will install the latest commit on your default branch (which right now is master). (This is also why I say git is also a makedepend, which just means it's a build dependency.)

from clog-cli.

BTW, if you do endorse this AUR package, you should make it clear that you yourself did not create, nor do you maintain it, so use at your own risk etc.

Because for example, I could (in theory) simply update the PKGBUILD to be malicious. Or what if my account gets comprimised by a malicious actor? etc. etc.

from clog-cli.

@vyp well, yes but they could also compromise my account. And hey I trust you because, we are both just random persons on the internet :)))

from clog-cli.

I think I'm going to re-address this soon to add something like what's mentioned in #3

Once #27 is merged, it'll be easier to add some of those settings. The initial implementation I'm thinking will allow for specifying the repo, and any custom aliases.

Perhaps a future addition would be allowing specification of custom sections as well. For example, right now we break out Features and Fixes, everything else gets ignored. This would allow a user to add a custom section that gets picked up into their changelog, and their own aliases for that section.

I'm thinking something like:

[sections]
Feature = [ "feat", "ft"]
Fix = ["fix", "fx"]
Performance = ["perf", "pf"]

# used in commit subjects like 
# myalias(component): my message
# or
# ma(component): my message
MySection = ["myalias", "ma"]

etc.

But again, this I think will be a future addition, for now let me just get the repo and custom aliases working :)

from clog-cli.

👍 I think that's a great idea. About the myalias, I'm also in favour of it (via the .clog file), because if the user wants to use that, then more power to them right?

However, a reason to not have that is that this starts (slightly) going away from the "conventional changelog standard" which angular.js sets out (did they 'invent' it?). Again, I'm for it, but @cburgdorf might have different opinion...

from clog-cli.

Good point. What I'd suggest then is that there is always at least the "conventional" sections. This would just allow users to add to, but not take away from them. So they could add their own aliases to the conventional sections, and add their own sections as well but not take away the conventional ones. Just a thought.

from clog-cli.

What I'd suggest then is that there is always at least the "conventional" sections. This would just allow users to add to, but not take away from them.

What happens if one of the aliases for MySection say has "feat" for whatever reason? What I mean is:

MySection = ["feat", "ft"]

I'm assuming that MySection here would refer to the words displayed in the changelog? So I think this should be allowed (e.g. to be able to override the default).

from clog-cli.

That'd be pretty easy to guard against, or detect. I'll wait for @cburgdorf guidance on if he'd rather exit with an error (i.e. no overriding or duplicate alias/sections), or let the user override a default with their own custom section/alias.

from clog-cli.

Basic implementation of this is done. See #27 for details, but the quick and dirty is it looks for a .clog.toml in your current working directory, and has support from repository, from-latest-tag, and subtitle

from clog-cli.

Perhaps a future addition would be allowing specification of custom sections as well

Sounds like a really good plan. 👍

Regarding

However, a reason to not have that is that this starts (slightly) going away from the "conventional changelog standard"

I'm personally ok with clog becoming more low level in a way that it allows completely different changelogs. If it's only becoming more flexible than what it is today I think we are pushing it into the right direction. We should have the conventional changelog as our benchmark in a way that we say "It should always be easy to configure clog to conform to the conventional changelog rules".

from clog-cli.

I'm personally ok with clog becoming more low level in a way that it allows completely different changelogs.

Awesome! 👍

from clog-cli.

Since the initial implementation of this is done. I'll call this closed (with 0d27d2f). It'll be easier to track new additions, or changes with individual issues. I'll create a .clog.toml label as well.

from clog-cli.