Skip to content

Stop save_locally defaulting to the installed package directory - #185

Open
caglarpir wants to merge 1 commit into
mapillary:mainfrom
caglarpir:fix-save-locally-default-path
Open

Stop save_locally defaulting to the installed package directory#185
caglarpir wants to merge 1 commit into
mapillary:mainfrom
caglarpir:fix-save-locally-default-path

Conversation

@caglarpir

Copy link
Copy Markdown
Contributor

save_locally declared:

file_path: str = os.path.dirname(os.path.realpath(__file__))

Python evaluates default arguments once, at import. So this resolves to the directory containing interface.pyinside site-packages. Calling save_locally() without an explicit file_path wrote user data into the installed package.

The docstring already said "Defaults to the current directory path", so the documented and actual behaviour disagreed.

Reproduction

From an unrelated working directory, on current main:

default path   : .../site-packages/mapillary
written into   : [".../site-packages/mapillary/probe_write.geojson"]
cwd contents   : []

The file lands in site-packages; the working directory stays empty.

Beyond being surprising, writing there can fail outright on a system-wide install where site-packages is not user-writable, silently pollutes the installed package, and loses the saved files on reinstall or uninstall.

Fix

Default file_path to None and resolve it to os.getcwd() at call time — which is what the docstring already described. Explicit file_path values are unaffected.

The two docstring examples that passed os.path.dirname(os.path.realpath(__file__)) now use a plain relative path, so they no longer suggest the old behaviour.

Behaviour change

This is a deliberate behaviour change, so it is split out from the metadata fixes in #184 rather than bundled. Anyone who was relying on the old default was relying on files landing in site-packages, which seems very unlikely to be intentional — but it is a change, and worth a maintainer’s eye rather than being slipped in.

Verified after the fix

default in signature : None
cwd after default    : ["probe_default.geojson"]
site-packages leaked : []
explicit path honored: ["probe_explicit.geojson"]
csv path             : ["probe_csv.csv"]
bad extension still  : InvalidOptionError

Unrelated bug noticed nearby (not fixed here)

Saving an empty FeatureCollection as CSV prints An error occurred: list index out of range and writes nothing. I confirmed this reproduces on unpatched main, so it predates this change — the CSV controller does not handle zero features and swallows the exception with a print. Left alone to keep this PR to one concern; happy to file it separately.

Test plan

  • pytest — 17 passed
  • black --check clean on the modified file, flake8 --select=E9,F63,F7,F82 — 0
  • Differential harness (41 probes): the only difference is the intended save_locally signature change

save_locally declared:

    file_path: str = os.path.dirname(os.path.realpath(__file__))

That default is evaluated once at import, so it resolves to the
directory containing interface.py -- i.e. inside site-packages. Calling
save_locally() without file_path therefore wrote user data into the
installed package rather than anywhere the caller would expect. The
docstring already claimed it defaults to the current directory, so the
documented behaviour and the actual behaviour disagreed.

Reproduced before the fix, from an unrelated working directory:

    written to: .../site-packages/mapillary/probe_write.geojson
    cwd:        []

Beyond being surprising, writing there can fail on a system-wide
install, silently pollutes the installed package, and loses the files on
reinstall or uninstall.

Defaults file_path to None and resolves it to os.getcwd() at call time,
which is what the docstring already described. Explicit file_path values
are unaffected. Docstring examples that passed the package directory
have been changed to a plain relative path so they no longer suggest the
old behaviour.
@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Sep 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant