opt-in nbOutDir and nbBaseDir

[HugoGranstrom]

This doesn't really solve the path problems we have right now, it's merely a band-aid on top that adds opt-in cmdline flags. In other words, it doesn't change the current behavior if no flags are passed.

The two flags are:

• -d:nbOutDir= which overwrites nbHomeDir
• -d:nbBaseDir= which is equivalent to nbSrcDir.

Still a few things to fix though.

[pietroppeter]

Great thanks! With names I would go with nimibOutDir and nimibSrcDir (so that we have package name as namespace and we can use later nbOutDir and nbSrcDir for the ones that we inject).

[HugoGranstrom]

Good idea, will change it! 👌

Right now nimibOutDir and nimibSrcDir are injected as well because that was the only way I could make the strdefine to work. I guess it's because it's in a template perhaps? I don't see a workaround to fix it currently but it's a const so it can't be changed. It could be confusing for the user if the autocomplete showed both nbSrcDir and nimibSrcDir but they'll learn eventually 😛

[HugoGranstrom]

Ok I don't think it was much more than this that's needed at the moment. Feels like unnecessary work to try and fix more stuff if it will be covered in a future refactoring either way :) So I'm fine with merging this now.

[pietroppeter]

I can understand that you might want to override nbHomeDir with an AbsoluteDir for the case of nimiboost (where you want a temp directory somehwere, right?). Not sure about nbSrcDir (better a relativeDir). Maybe for the moment we skip the override for srcDir (I do not think it is needed for nimibook, right)?

[HugoGranstrom]

Yes nbHomeDir is very useful if it's a absolutedir but nbSrcDir is not neccecary for NimiBoost. I would just set it to "." either way. I could probably do with a relative dir for nbHomeDir as well honestly, because of the restrictions of VSCode extensions I have to create the temp folder in the project itself (and delete them when the window is closed). I tried and toAbsoluteDir accepts both relative dirs and absolute dirs and converts it into an AbsoluteDir so it's not like we can't use relative dirs, but it's perhaps the fact that the variable itself is absolute instead of relative that bothers you?

But yes we can skip nimibSrcDir for now, I'll fix it later today 😄

[pietroppeter]

I tried and toAbsoluteDir accepts both relative dirs and absolute dirs and converts it into an AbsoluteDir so it's not like we can't use relative dirs, but it's perhaps the fact that the variable itself is absolute instead of relative that bothers you?

you are right toAbsoluteDir does check if it is absolute otherwise converts it to Absolute considering current dir (source), so it is all fine. And for SrcDir ok to skip it for now, since it is not even officially in nimib.

[HugoGranstrom]

you are right toAbsoluteDir does check if it is absolute otherwise converts it to Absolute considering current dir (source), so it is all fine.

Great! 👍

And for SrcDir ok to skip it for now, since it is not even officially in nimib.

That's a fair point. I noticed when I removed it though that I was in need of it after all. It has to do with the fact that nbDoc.filename is an absolute path at the moment. So unless I have a way of manipulating it, it will just put the .html file besides the .nim file instead of in nbHomeDir. So I'm in need of some way of making nbDoc.filename into a relative path instead so the withDir(nbHomeDir) has any effect. And it was that problem that nimibSrcDir solved. Do you have any other suggestions on how to solve this?

[pietroppeter]

yeah, in principle we could set filename as a relative dir, relative to nbHomeDir, but since this can break stuff, I guess the bets way is to actually use the SrcDir mechanism.

[HugoGranstrom]

Setting it relative to nbHomeDir wouldn't work as we are setting the final path relative to nbHomeDir. For example if we save it in docs/ then index.nim would have the relative path ../book/index.nim so when we write it finally we do it at nbHomeDir/../book/index.html which is still in the book dir instead of the docs dir as intended. Therefore we will need to have nbHomeDir and nbSrcDir as separate things. What is in nbSrcDir gets mirrored into nbHomeDir.

So it's a keep for now?

[pietroppeter]

this says toAbsoluteDir but it should actually be a toAbsoluteFile. Should we use toAbsolute with nbHomeDir as base?

[HugoGranstrom]

Oops, good catch should indeed be File and not Dir 😄
Not really sure exactly how you intend to use toAbsolute here. Add it to the existing code or replace the existing code with it? It has a check that if the file-path is already absolute it will ignore the the base.

[pietroppeter]

Not sure either how to use it but there is not a toAbsoluteFile available right?

[HugoGranstrom]

Oh right, just assumed it did exist... Yes then we have to use it or AbsoluteFile(file) which it uses internally. That is if we know that nbDoc.filename is a absolute path to begin with...

If nbDoc.filename is absolute (currently the case) it doesn't matter what base is because it won't be used. If it on the other hand is a relative file then we'd want it to return its actual path in the nimibSrcDir to be able to give the correct relative path later for saving the file in nbHomeDir. This is why we need nimibSrcDir to begin with. So it depends on what the relative path is relative to I guess. But I don't think using nbHomeDir as base will work in any of the cases.

I think what would work best as base in this case is nimibSrcDir as one will be able to use it in the future to redefine relPath to use it instead of nbHomeDir. This was the way we did it in the early versions of getting-started as well, setting paths relative to nbSrcDir: https://github.com/SciNim/getting-started/blob/a15d840fda541730fe9c513cbefeb1ca04fedce3/nbPostInit.nim#L2

[HugoGranstrom]

Ok think I've got this sorted now. We split it into two scenarios:

• nbDoc.filename.isAbsolute: We calculate the relative path from nimibSrcDir
• isRelative: we do nothing, we trust the user has already set it to the appropriate relative path.

How does this sound?

[pietroppeter]

sounds good! 🚀

[pietroppeter]

yes, it is a keep for now. We will clean up later. Added just one question on the implementation but design for me is approved.

[HugoGranstrom]

Ok then, everything should be ready now :)

[pietroppeter]

thanks, I will cut a release now!

[HugoGranstrom]

Awesome! 😄 Will try to incorporate it into NimiBoost tomorrow. (And then I'll be satisfied enough with it to make the first release so you can try it as well 🙃)