add path replace-extension to stdlib-candidate

[WindSoilder]

This pr is trying to add a useful custom command which is mentioned here: nushell/nushell#14144

I think it's useful to play with file extensions.

---

This pr also set up testing for candidates. In order to do this, I made some changes:

1. ported nu-std/testing.nu under stdlib-candidate folder, and making some changes.
2. run candidate tests in toolkit check pr command, to make sure the test is run in CI.
3. including stdlib-candidate to NU_LIB_DIRS when running lint, so the tests can pass linter.

Changes in stdlib-candidate/testing.nu:

1. remove std/log usage
2. including stdlib-candidate path in run-test command

[fdncred]

I think we need tests for stdlib candidates please.

[NotTheDr01ds]

@fdncred As part of the updated README, I included the following:

• Include doc comments for definitions and parameters that can be used with help
• Include tests

The last two (doc and tests) do not need to be in place at the time of the initial inclusion in stdlib-candidate, but are, of course, required in order to promote to std.

We can revise that if need be. My thoughts on this were that not everything we put in std-rfc is going to get promoted, so perhaps requiring tests at this stage is perhaps unnecessary?

[fdncred]

I think it's a mistake to not require tests for candidates.

[WindSoilder]

OK, I think it's good to add tests for candidates.
I added them and update the pr description

[fdncred]

Thanks for all the changes. I personally think it's good to have these test mechanisms in here.

I think this command needs a bit of clarification. It claims to update the extension of files, which it can be argued that it does that. But it doesn't really change the extension of files, does it? If there are files on the file system, they will be unchanged. It seems to only change the text in a table that contains file names. So, the file names are never changed with this command, correct?

[WindSoilder]

Yeah it doesn't change the file name locally. I updated the doc

[NotTheDr01ds]

What do you think about naming this something like path replace-extension.

path extension sounds like it's retrieving the extension.

Also, as I mentioned in the original feature request, this doesn't appear to handle "complex" extensions like we do with path parse --extension. The common case, of course, is .tar.gz. That's probably a minor issue.

I still think that the following is so straightforward that I personally don't see much of a need for this as a std command.

'sample.json' | path parse | $"($in.stem).nuon"
# => sample.nuon

But I'll defer to others if they feel it's important.

[WindSoilder]

TBH I still think a command is good for it. And path replace-extension can also handle list input.

If using string interpolation approach, when we meet a list, it's required to use each:

['sample.json', 'sample2.json'] | path parse | each {|it| $"($it.stem).nuon"}

Though it's not a big deal.

I have renamed the command.
I'd vote it to be nu-std, but I will obey the final decision.

[NotTheDr01ds]

I say we land it, advertise it and ask for feedback via Showcase, and then evaluate in a month or so whether we want to promote it to std or not.

[132ikl]

I just noticed that this should be in the std-rfc folder, not the root level stdlib-candidate folder