default location for juliapkg.json

[oxinabox]

[project is location:] If you are in a Python virtual environment or Conda environment, then {env}/julia_env subdirectory is used.
[juliapkg.json location] {project}/pyjuliapkg where project is as above (depending on your environment).

These seems non-ideal.
Since normally one would git-ignore this directory.
Since it can be recreated by venv or conda. (or pixi in my case, but that looks like conda for this purpose).

This location makes sense to be where you install things to.
But not for where the file that specifies what you want to install lives.

I would think that it would want to live in same directory as pixi.toml/pyproject.toml/requirements.txt/environment.yml

[cjdoris]

I see your point but it's not obvious where else juliapkg could look for this file.

We could add an env var PYTHON_JULIAPKG_DEPS (say) to specify where to look for juliapkg.json. It would nicely complement PYTHON_JULIAPKG_PROJECT for specifying the project location.

[oxinabox]

I don't really know how to workout locations of files in python.

If it is running in pixi then the environment variable PIXI_PROJECT_ROOT gives that right location.
Maybe there is a list of enviroment variables like that one for different python package managers?

I guess something like looking in the conda enviroment and see if only 1 package is dev'd and then use that project root directory?

Or maybe ther is something that can be done by walking up the directory structure looking for the file?

[cjdoris]

The trouble is that juliapkg is a package that may be invoked without user intervention, so the behaviour needs to be rock-solid and not guess things. Whereas package managers like Pixi can be a bit more loose because they are explicitly invoked by the user, who implicitly agrees to have their environment a certain way.

I didn't know about PIXI_PROJECT_ROOT. We could look there and if it has a juliapkg.json file then treat that as the project-level one.

However there won't always be such a hint. Indeed, you can create a python virtual environment using python -m venv which has no notion of a project root.

I'm a bit wary of locking into different package managers too much.

Things like searching from the current working directory feels too much like guesswork.

What feels (only slightly) less like guesswork is searching up directories starting from the venv/conda env, since these are often put within the project folder.

[cjdoris]

A little reading later...

A python virtual environment always has a pyvenv.cfg file at its root. At a minimum it specifies where Python's stdlib lives, which isn't in itself useful. However it can contain other info, for example uv sets a bit of info which at least lets us detect if uv created it.