Provide absolute file path to `--project` flag

[matthewgrossman]

After struggling to get my server's python.analysis.* settings to apply, I stumbled across https://github.com/DetachHead/basedpyright/issues/513 and realized my issue was that a minimal pyproject.toml in the project was overriding all of my editor config. I overall agree with the conclusion in that thread around consistent project configuration (and why merging local + repo config can cause issues), but I'd still like the ability to use my own configuration in certain scenarios.

I thought I found a way of doing that: the --project flag. However, I can't seem to get the server to actually respect the filename that I pass in here. Presumably, this is because it ends up doing some path arithmetic using the cwd() as the base, which doesn't work with the absolute path of /Users/mg/dotfiles/config/pyproject.toml that I'm trying to pass in:

https://github.com/DetachHead/basedpyright/blob/4a9ba0d3870a5320603edcab4a5ff5f0f8d9ef96/packages/pyright-internal/src/pyright.ts#L300-L302

So my questions:

• Is there any way to completely ignore all pyproject.toml discovery that basedpyright tries to do, and instead just rely on the server's settings? AFAICT, it seems like the answer is "no", which is what led me to this --project solution.
• Could it make sense to adjust how the configFilePath is calculated in instances that the CLI flag is an absolute path? Happy to contribute if that makes sense. Would proposing that modification in upstream pyright be preferable?

Thanks!

[DetachHead]

yeah theres currently a few options that expect a relative path and don't work on an absolute path, such as ignore (https://github.com/DetachHead/basedpyright/issues/725). there's also venvPath which is the opposite and only works on absolute paths (https://github.com/DetachHead/basedpyright/issues/365#issuecomment-2119108050)

the way i see it, all options that take a path should work on both absolute and relative paths, regardless of anybody's opinion regarding their use cases.

[matthewgrossman]

Got it, thanks for the quick response.

Is my understanding of that first question correct as well?

Is there any way to completely ignore all pyproject.toml discovery that basedpyright tries to do, and instead just rely on the server's settings? AFAICT, it seems like the answer is "no", which is what led me to this --project solution.

[DetachHead]

yeah as far as i know there's no way to do that. and from the discussion on that other issue i don't think it's a good idea to support it. but i still think --project should work with absolute paths, which may be a suitable workaround as you mentioned, but im not 100% sure it'll work for this use case

but I'd still like the ability to use my own configuration in certain scenarios.

i'm curious what these scenarios are. if you're working on a project that defines its own (based)pyright config, how come you want to override it with your own settings?

[matthewgrossman]

i'm curious what these scenarios are.

I'm working in a decently-sized monorepo (many libraries and services) that does not use pyright at all in CI. We have a variety of CI checks (isort/black/pytest), but pyright itself is only used for local developer machines: type-related errors, autocomplete, jump-to-def, etc.

Our developers use different editors (primarily pycharm/vscode/neovim), and at some point in time, one developer checked in a pyproject.toml with a very minimal [tool.pyright] setup.

The setup that they have checked in does not match the setup that I want. Specifically, I want to disable most of the linting which overlaps with ruff; having the overlapping errors is annoying, especially considering when there's a delay in pyright's updates (ruff of course being much faster).

So here's my options:

1. Try to get our pyproject.toml to remove [tool.pyright]. This means placing the burden of configuring pyright back onto the each individual user's editor. It's unclear to me how many developers (perhaps unknowingly) depend upon this, and I don't want to mess with their setups since they are presumably content with the status quo.
2. Add in my specific settings to the [tool.pyright] section. Since most of my changes involve disabling various diagnostics, this would have the same issue as (1); affecting other developers who depend upon this current setup.
3. Update our project's pyproject.toml to include my desired pyright and ruff settings, ensure CI runs these settings, and ensure each developer has these tools/linters installed locally as well. This a much larger effort, perhaps made easier with something like pre-commit.com, but still a large chunk of work.
4. Ignore the settings defined in the repo and just roll my own setup, based upon server settings or a global-dotfiles pyproject.toml. That's what I'd like to do, and what this issue is about enabling
5. Disable all linting from pyright so I can use it just for autocomplete/jump-to-def, and use mypy for type-checking and ruff for linting. That's what I'm currently leaning towards, unfortunately

I think the key aspect here is that pyright doesn't run in CI, and is really just (optionally) used as an aide to developers. In fact, I'm sure most of our developers don't use it at all, since they'e running python within pycharm, and just rely on the default setup there.

An analogy would be if the pyproject.toml dictated syntax colorschemes on my own local machine, or font size. While developers might appreciate the defaults checked into the repo to give everyone a uniform experience, they likely want to be able to override those suggestions and use whatever they want in their day-to-day.

[DetachHead]

it's crazy to me hearing what other developers have to deal with lol. i'm very particular about how projects i work on should be set up so i guess i'll share my thoughts on your situation.

1. Try to get our pyproject.toml to remove [tool.pyright]. This means placing the burden of configuring pyright back onto the each individual user's editor. It's unclear to me how many developers (perhaps unknowingly) depend upon this, and I don't want to mess with their setups since they are presumably content with the status quo.
2. Add in my specific settings to the [tool.pyright] section. Since most of my changes involve disabling various diagnostics, this would have the same issue as (1); affecting other developers who depend upon this current setup.

any config file that gets committed should either be used by everyone working on the project, or not interfere with the config used by everyone else working on the project. if your project does not use (based)pyright, that config should be removed.

3. Update our project's pyproject.toml to include my desired pyright and ruff settings, ensure CI runs these settings, and ensure each developer has these tools/linters installed locally as well.

this is what i'd recommend. configuring all this can be a huge pain, but it's totally worth it and it makes your experience so much less frustrating when the errors you see in your IDE are the same as the errors everyone else sees in their IDEs and in the CI.

This a much larger effort, perhaps made easier with something like pre-commit.com, but still a large chunk of work.

i'd suggest avoiding pre-commit. the guy who made it is a massive asshole so you'll have a bad time if you encounter any issues with it. just look at how he talks to people.

also its just a worse solution to the problem anyway imo

4. Ignore the settings defined in the repo and just roll my own setup, based upon server settings or a global-dotfiles pyproject.toml. That's what I'd like to do, and what this issue is about enabling

i can see why you're leaning towards this option, however i still highly recommend option 3. or if that's not feasible, i suggest option 1. (not sure what your team is like, but hopefully the developer who committed their personal config will understand your point if you explain to them that it's interfering with your personal config)

In fact, I'm sure most of our developers don't use it at all, since they'e running python within pycharm, and just rely on the default setup there.

i'm in the same boat in my project at work as a vscode user in a team full of pycharm users. i've invested so much time configuring everything in vscode to match the behavior of the CI, in fact the reason i even started basedpyright in the first place was because it was impossible to do this with pyright/pylance. yet most people in my team for some reason still use an IDE with such busted type checking that they just ignore all of its errors anyway, it renders all my efforts useless (they even refuse to use the pyright pycharm plugin for some reason).

An analogy would be if the pyproject.toml dictated syntax colorschemes on my own local machine, or font size. While developers might appreciate the defaults checked into the repo to give everyone a uniform experience, they likely want to be able to override those suggestions and use whatever they want in their day-to-day.

i don't think this is really comparable, not just because such settings are never used in CI, but because code committed by someone using a different font to you will never cause issues on your machine, whereas code committed by someone using less strict type checking rules will cause errors to appear in your IDE. then you have the problem where it's difficult to identify which of the hundreds or errors you see were actually caused by you.