Update to the new release of FilePathsBase

[rofinn]

This depends on the new FilePathsBase version being released.

[oxinabox]

Are we accessing fields on AbstractFilePaths?

[rofinn]

Sort of. All types should have at least have a field called segments and everything else like drive and root will have abstract defaults.

[oxinabox]

Can you fill me in on why the use of getproperty and having required fields on all subtypes of an abstract type is better?
I liked the way it was before, I feel like I can trust function calls.

[rofinn]

It’s mostly a namespacing issue for generic names like root, drive and parts. Also, parts and segments have different behaviour now. The reason this changed is that getproperty can be used as a way of handling depreciations now.

[oxinabox]

hmm, the namespacing use-case is interesting. Still not sure how I feel about this though.

[rofinn]

That's part of the reason we don't have a 1.0 release yet. I figured we should try the getproperty approach for a bit to see how that works. If it's too awkward we can always go back to accessor methods.

[oxinabox]

ok, I am down with exploring it and trying it out.

This looks fine, fix CI before merging yes?

[davidanthoff]

@rofinn and @oxinabox could we tag and release a version here ASAP? Right now the whole released versions are broken because one gets the latest version of FilePathsBase, which removes functions like root, in combination with the latest FilePaths, which requires the root functions.

This is causing a major headache right now for a workshop that I have to teach tomorrow :) I'll also try to add the appropriate bounds to the registry now.

[rofinn]

Shouldn't FilePaths.jl be upperbounding FilePathsBase? Oh, damn, I forgot to tag a release after dropping the REQUIRE file. And the METADATA synching didn't place an upperbound.