Project cleanup

[ngie-eign]

• Add python 3.13/3.14 support.
• Replace defunct pysqlite3 dependency with sqlite3 dependency.
• .gitignore: add more paths.
• Apply ruff fixers:
  • ANN (all)
  • I (all)
  • UP (all)
  • Others (safe only)
• Fix a potential SQLite3 injection attack.
• Use non-legacy (native) type hints.
• Run through ruff format.

[ngie-eign]

pkg install py311-hatch didn't work on 14.4-RELEASE BTW due to the latest version being out of date/incompatible with the version of virtualenv we distribute on 14.4-RELEASE right now for issues discussed in the 1.16.5 release notes.

[markjdb]

Please don't reformat all of the code, it makes history unreadable for no benefit and gives me a bunch of work to do when rebasing local WIP patches. I don't want to take these "chore" patches.

If you want to make the code compliant to some linter or type checker, please at least include a script so that others can easily lint their changes.

[markjdb]

There is no "attack": restype's value is defined within the code itself, and the user invoking bricoler already has control over the db file. Please don't use such language for benign things.

[ngie-eign]

I realize the wording is potentially inflammatory: it should state that the new code applies a best practice and the old code was prone to an SQL injection attack in general, but the code itself wasn't vulnerable due to how it's designed.

[markjdb]

I find this less readable than before.

[ngie-eign]

# fmt: skip could avoid that kind of reformatting. I'll save that for when I get to that part of this larger diff.

[ngie-eign]

If you want to make the code compliant to some linter or type checker, please at least include a script so that others can easily lint their changes.

That's a fair ask. pre-commit integration is the best way to handle this generally.

[ngie-eign]

Please don't reformat all of the code, it makes history unreadable for no benefit and gives me a bunch of work to do when rebasing local WIP patches. I don't want to take these "chore" patches.

It makes life more difficult when contributing back changes to improve the tool though when there isn't a baseline/automation bar being applied to bricoler.

.gitignorerevs would definitely aid with large formatting commits like this, but I agree that (in general), some of the other items should be cleared out of the way before moving on to this larger (mostly, but not completely) mechanical change.

#29 and #30 whittle away at this work a bit, but this project is definitely deserving of tests (#30 breaks initial ground, but a lot of coverage areas are missing).

I see bugs in the code as it exists today -- if more tests existed, I feel that some of the issues would be more apparent/more quickly addressed.

[markjdb]

Please don't reformat all of the code, it makes history unreadable for no benefit and gives me a bunch of work to do when rebasing local WIP patches. I don't want to take these "chore" patches.

It makes life more difficult when contributing back changes to improve the tool though when there isn't a baseline/automation bar being applied to bricoler.

Reformatting all of the code doesn't apply a "baseline/automation bar" though?

For now I prefer to prioritize not making my own life more difficult. Bug fixes, new features are welcome, "cleanup" not so much.

.gitignorerevs would definitely aid with large formatting commits like this, but I agree that (in general), some of the other items should be cleared out of the way before moving on to this larger (mostly, but not completely) mechanical change.

#29 and #30 whittle away at this work a bit, but this project is definitely deserving of tests (#30 breaks initial ground, but a lot of coverage areas are missing).

I see bugs in the code as it exists today -- if more tests existed, I feel that some of the issues would be more apparent/more quickly addressed.

What bugs are you referring to?

[ngie-eign]

Reformatting all of the code doesn't apply a "baseline/automation bar" though?

For now I prefer to prioritize not making my own life more difficult. Bug fixes, new features are welcome, "cleanup" not so much.

Right now contributors are required to handle reformatting/linting/etc on their own, which is extremely error prone and results in unnecessary debating over style and such. Leveraging tools like black, ruff, etc, allow you (and the project as a whole) to focus on what the code does more than how it's presented, and helps avoid defects by leveraging tools which find bugs for you.

What bugs are you referring to?

65e3505 is the first one I've found, but one can argue that 2e0b6fe is also a bug since it mangles the traceback stack. The latter is less of an issue with python 3 thanks to exception chaining, but it was definitely a problem with python 2; I received a few defects back in the day at another job due to an issue like this (turns out the real defect was in another piece of code).

[markjdb]

Reformatting all of the code doesn't apply a "baseline/automation bar" though?
For now I prefer to prioritize not making my own life more difficult. Bug fixes, new features are welcome, "cleanup" not so much.

Right now contributors are required to handle reformatting/linting/etc on their own, which is extremely error prone and results in unnecessary debating over style and such. Leveraging tools like black, ruff, etc, allow you (and the project as a whole) to focus on what the code does more than how it's presented, and helps avoid defects by leveraging tools which find bugs for you.

At this point it's better to minimize dependencies. If the project gets big enough, things like this will make more sense. For now I'd like to keep it simple(r).

What bugs are you referring to?

65e3505 is the first one I've found, but one can argue that 2e0b6fe is also a bug since it mangles the traceback stack. The latter is less of an issue with python 3 thanks to exception chaining, but it was definitely a problem with python 2; I received a few defects back in the day at another job due to an issue like this (turns out the real defect was in another piece of code).

Both of these bugs are harmless.

[ngie-eign]

Reformatting all of the code doesn't apply a "baseline/automation bar" though?
For now I prefer to prioritize not making my own life more difficult. Bug fixes, new features are welcome, "cleanup" not so much.

Right now contributors are required to handle reformatting/linting/etc on their own, which is extremely error prone and results in unnecessary debating over style and such. Leveraging tools like black, ruff, etc, allow you (and the project as a whole) to focus on what the code does more than how it's presented, and helps avoid defects by leveraging tools which find bugs for you.

At this point it's better to minimize dependencies. If the project gets big enough, things like this will make more sense. For now I'd like to keep it simple(r).

What bugs are you referring to?

65e3505 is the first one I've found, but one can argue that 2e0b6fe is also a bug since it mangles the traceback stack. The latter is less of an issue with python 3 thanks to exception chaining, but it was definitely a problem with python 2; I received a few defects back in the day at another job due to an issue like this (turns out the real defect was in another piece of code).

Both of these bugs are harmless.

The former bug prevents makefs from actually running. Is it really harmless?

Reformatting all of the code doesn't apply a "baseline/automation bar" though?
For now I prefer to prioritize not making my own life more difficult. Bug fixes, new features are welcome, "cleanup" not so much.

Right now contributors are required to handle reformatting/linting/etc on their own, which is extremely error prone and results in unnecessary debating over style and such. Leveraging tools like black, ruff, etc, allow you (and the project as a whole) to focus on what the code does more than how it's presented, and helps avoid defects by leveraging tools which find bugs for you.

At this point it's better to minimize dependencies. If the project gets big enough, things like this will make more sense. For now I'd like to keep it simple(r).

What bugs are you referring to?

65e3505 is the first one I've found, but one can argue that 2e0b6fe is also a bug since it mangles the traceback stack. The latter is less of an issue with python 3 thanks to exception chaining, but it was definitely a problem with python 2; I received a few defects back in the day at another job due to an issue like this (turns out the real defect was in another piece of code).

Both of these bugs are harmless.

The first bug looks very valid since makefs uses getopt for option parsing (unless the code as written is completely dead):

% cc -o getopt_mash -Wall getopt_mash.c
% ./getopt_mash                      
getopt returned: -1
% cat getopt_mash.c                    
#include <stdio.h>
#include <unistd.h>

int
main(void)
{
        char *const mock_argv[] = {
                "-oversion=2"
        };
        int ch = getopt(0, mock_argv, "o:");
        printf("getopt returned: %d\n", ch);

        return (0);
}

[markjdb]

Reformatting all of the code doesn't apply a "baseline/automation bar" though?
For now I prefer to prioritize not making my own life more difficult. Bug fixes, new features are welcome, "cleanup" not so much.

Right now contributors are required to handle reformatting/linting/etc on their own, which is extremely error prone and results in unnecessary debating over style and such. Leveraging tools like black, ruff, etc, allow you (and the project as a whole) to focus on what the code does more than how it's presented, and helps avoid defects by leveraging tools which find bugs for you.

At this point it's better to minimize dependencies. If the project gets big enough, things like this will make more sense. For now I'd like to keep it simple(r).

What bugs are you referring to?

65e3505 is the first one I've found, but one can argue that 2e0b6fe is also a bug since it mangles the traceback stack. The latter is less of an issue with python 3 thanks to exception chaining, but it was definitely a problem with python 2; I received a few defects back in the day at another job due to an issue like this (turns out the real defect was in another piece of code).

Both of these bugs are harmless.

The former bug prevents makefs from actually running. Is it really harmless?

No it does not. Yes.

The first bug looks very valid since makefs uses getopt for option parsing (unless the code as written is completely dead):

% cc -o getopt_mash -Wall getopt_mash.c
% ./getopt_mash                      
getopt returned: -1
% cat getopt_mash.c                    
#include <stdio.h>
#include <unistd.h>

int
main(void)
{
        char *const mock_argv[] = {
                "-oversion=2"
        };
        int ch = getopt(0, mock_argv, "o:");
        printf("getopt returned: %d\n", ch);

        return (0);
}

This getopt() call isn't even looking at the "-oversion=2" string, for two reasons: you're passing argc==0, and optind is 1 by default. So it's immediately at the end of the argv, and it returns -1 to signal that.

[ngie-eign]

Reformatting all of the code doesn't apply a "baseline/automation bar" though?
For now I prefer to prioritize not making my own life more difficult. Bug fixes, new features are welcome, "cleanup" not so much.

Right now contributors are required to handle reformatting/linting/etc on their own, which is extremely error prone and results in unnecessary debating over style and such. Leveraging tools like black, ruff, etc, allow you (and the project as a whole) to focus on what the code does more than how it's presented, and helps avoid defects by leveraging tools which find bugs for you.

At this point it's better to minimize dependencies. If the project gets big enough, things like this will make more sense. For now I'd like to keep it simple(r).

What bugs are you referring to?

65e3505 is the first one I've found, but one can argue that 2e0b6fe is also a bug since it mangles the traceback stack. The latter is less of an issue with python 3 thanks to exception chaining, but it was definitely a problem with python 2; I received a few defects back in the day at another job due to an issue like this (turns out the real defect was in another piece of code).

Both of these bugs are harmless.

The former bug prevents makefs from actually running. Is it really harmless?

No it does not. Yes.

The first bug looks very valid since makefs uses getopt for option parsing (unless the code as written is completely dead):

% cc -o getopt_mash -Wall getopt_mash.c
% ./getopt_mash                      
getopt returned: -1
% cat getopt_mash.c                    
#include <stdio.h>
#include <unistd.h>

int
main(void)
{
        char *const mock_argv[] = {
                "-oversion=2"
        };
        int ch = getopt(0, mock_argv, "o:");
        printf("getopt returned: %d\n", ch);

        return (0);
}

This getopt() call isn't even looking at the "-oversion=2" string, for two reasons: you're passing argc==0, and optind is 1 by default. So it's immediately at the end of the argv, and it returns -1 to signal that.

Yeah, I see where I botched that example now. I'll just close this PR and #30 . I'll leave #29 to you as to whether or not you want to take that PR.