Specify a relative path to charm using `jhack sync`

[akram09]

Hello ! I have a small feature request regarding the jhack sync command. In some charms in the Data Platform team we are using a concept called single-kernel where we have a pip package holding most of the charm code and use it in different charm substrates. For instance in opensearch we have opensearch_single_kernel, so if I have a running instance of the charm and want to sync it with local code I would have to do the following
jhack sync --source ./opensearch_single_kernel/ --remote-root /var/lib/juju/agents/unit-opensearch-0/charm/venv/lib/python3.12/site-packages/opensearch/0

While this is actually fine, it is still bothering that I have to specify the full path which depends on the unit name each time I want to sync. Therefore I would like to know if it would be possible to have a different parameter to specify the relative path to the actual charm directory. I saw there is an option to specify venv but this would sync all the venv folder which is not really what we want here.

I had a discussion with @Gu1nness as well, and it seems it would be a a good add-ons to have since we are also following the same architecture for Mongodb.

Thank you !

[PietroPasotti]

I've usually been doing that with --venv: you run jhack sync --venv, then you do 'uv sync' (or update your .venv somehow), and that gets reflected in the charm. But I can see that having a more direct, hands-off path could be nice.

Thinking about the API...

I think this could be implemented easily enough as a '--single-dependency' flag? Semantics: "watch this python package, and anytime it changes, push it to this charm's venv".
OTOH this strategy would make the new flag mutually exclusive with --venv and --container and --remote-root, which adds a little UX awkwardness, but perhaps it's tolerable.

WDYT?

[Gu1nness]

That's probably a good idea !

Maybe it's possible from typer's side to make those flags mutually exclusive ?
Or even jhack sync-dependency, creating a new command for that (so that it's really mutually exclusive)

I'm also wondering on the impact if you're using jhack sync without specifying a unit (probably less drastic than the regular jhack sync on on all targets where you could be replacing all targets' charm.py which would probably bork everything.)

[PietroPasotti]

I don't think we need to worry about users syncing to whole apps, that's sync behaviour already and shouldn't be surprising.
About making it a separate command, yes, but... that's 90% duplication we're looking at, so I'm leaning towards accepting the validation awkwardness.

[akram09]

Thats a great idea. I think it will be a good addition to jhack. I would personally opt for having it as a separate flag instead of adding a special command just for this. It would maybe also make more sense that user specify the venv and only select one dependency to be watched. So it's more of a filtering flag.

[PietroPasotti]

I can work on this when I have time (next week), or if you would like to pick it up, just say the word :)

[akram09]

Sure @PietroPasotti , I would like to do that 👍