Up ? Is any seasoned contributor available to answer my questions and help me get this PR in a mergeable state ? :)

SupportFuncs just determine what functions are in the supports_{fd,dir_fd,follow_symlinks} sets. For chown, it looks like it supports dir_fd and follow_symlinks, so you can put None, Some(true), Some(true). I think the Options are because some functions are supposed to support one of them but they don"t yet, so we put None for that as a sort of TODO. I think.

Oh, and yeah, you can ignore the auditing events stuff.

I fixed the clippy lint.

SupportFuncs just determine what functions are in the supports_{fd,dir_fd,follow_symlinks} sets. For chown, it looks like it supports dir_fd and follow_symlinks, so you can put None, Some(true), Some(true). I think the Options are because some functions are supposed to support one of them but they don"t yet, so we put None for that as a sort of TODO. I think.

I also fixed this, thanks. Do you think it could be usefull to refactor this weird Option into a cleaner enum then ? Something like

enum SupportStatus {
    SUPPORTED,
    TODO,
    NOT_SUPPORTED,
}

I"ll gladly open a PR for this if you think this is useful.

Finally, I"d feel more confident if I wrote at least unit tests for this piece of code. I can write some rust tests on the rust function but I think that it misses the point and I"d rather write python tests where I actually call the function os.chown from python code (liek integration testing)
There was nothing in the CONTRIBUTING.md file regarding the tests, what do you expect and where are these kind of tests located in the codebase ? I feel like it"s important to write them as we add more functions to the python library to make sure there are no regressions whatsoever.

Yeah, I think the 3-enum rather than the Option<bool> would definitely make it more clear.

re: unit testing; there is a test_os module in CPython that we could copy over, but it"s ~4000 lines and with just a naive copy over there"s 95 failing tests. You could write a few tests in tests/snippets/stdlib_os.py, though, maybe take inspiration from the chown tests in CPython?

Ok the CPython tests are a nice resource indeed ! I"ll try to draw inspiration from these for sure, and maybe add a few more test cases.

Regarding the issue I mentioned in my original comment regarding the tilde expansions, it seems that neither Rust nor Python do it, so I won"t add support for it.

Ah, yeah, I think you have to manually opt in to that with os.path.expandpath(p)

Just wrote a first few tests (mostly copied from CPython test suite) and I have a few things to say:

• Overall the way testing is done for snippets (Lib) seems super messy and counterintuitive to me. I rather prefer the CPython test suite organisation with clear separation between function being tested, separation of tests cases, and so on. The strange custom runner you"re using is not making a lot of sense to me atm so I"ll gladly take any clarifications on this.
• Partly because of the first point, I have not a lot of trust in the tests I wrote since there is very little observability on what is running or not inside the tests files. Mainly on the fact that for chown the test suite needs to be started with and without sudo permissions to test both behaviours. Again, if you have any idea or clarification on that, I"ll gladly hear them.

Regarding the CI failing, it seems that with rust stable bumping to 1.45 today, clippy is now more restrictive on certain things and code that was previously considered correct is no longer. It should eventually be fixed in another PR.

Regarding the sister functions of chown (lchown, fchown, ...), I will add them so please don"t close this PR now.

Regarding the adding of an enum for SupportFuncs, I will move this to another PR to keep things clean.

As I am a newcomer on this project and that PR got me to take a look around a few parts of it (namely the standard lib and the integration tests), I will write down my take on this "experience" and on the entry barrier to new contributors as I perceived it. The architecture of the Lib reimplementation could be improved by creating rust module for each library module and creating a single file for each function in this module. That way, code would be cleaner, it would reduce conflicts, it would allow us to write clean rust unit tests in each file to test only a function, without cluttering an already too large file. (eg the os file is already more than 2300 loc and we are far from having everything implemented)
My second point refers back to the test suites and more particularly the snippets. I feel like everything is over-complex and sub-performant. The test files are a mess with no clear organisation and separation. It"s like a gigantic plate of spaghettis.
Of course, this is an open source project with limited contributing workforce and time and I get these points are not a priority. But as a newcomer, I faced them almost instantly and I understand it can discourage people from making polished and well-tested contributions. I would then happily discuss these points with maintainers and open the needed issues to try and improve the codebase if this makes sense as well as the developer"s guidelines. I believe that properly testing the Lib as we add pieces to it is the best way to go, that it is fun to do, and that it is a good way to bring in new contributors with a myriad of self-contained PRs that would encourage best coding practices, mix rust and python and quickly obtain a nice and satisfactory finished new feature.
(All the paragraph above is my personal view on the subject, with the eyes of a newcomer, it might be totally wrong and subject to change)

Yeah, the test snippets aren"t very well organized, partly because we don"t need them to be; the idea is that we just have a bunch of snippets that assert some basic functionality, and eventually we"ll try to rely more on the CPython test suite to ensure that we have parity. I definitely do understand that it might be confusing for new contributors, though, we should explain that more in tests/README.md. Just know that we know that they"re a mess, but our main focus w.r.t testing is getting the Lib/test suite to work.

Also, the clippy lints should be fixed on master now.

I just added support for fd and sister functions fchown and lchown, I think that the PR is mergeable now. Let me know if there is anything to alter still.