Use local packages in pyproject.toml

[sublime-coleslaw]

Using local packages instead of versioned pypi packages allows for instant updates to sub-packages without needing to create a new release. Packages can now be installed with one poetry install command in the root librelingo project.

Version drift between sub-packages is also stopped. It's impossible for librelingo-json-export and librelingo-yaml-loader to depend on different versions of librelingo-fakes.

#3023

#2763

[kantord]

but this would completely break all PyPI packages published from this repo, no? basically it will no longer be possible to install the packages from PyPI, just from this repo. That would be a problem because there are other apps, such as Glossaico that already depend on those packages and they would like to depend on them still: https://codeberg.org/dimkard/glossaico

[kantord]

I think that to solve the bugs that you mentioned it could be enough to remove all need to manually install those packages, except in the publish process. They are still needed for the publish process in PyPI. But they should not be needed for local development at all as there is a common shared virtualenv created for the whole repo and it's already configured in a similar way: https://github.com/LibreLingo/LibreLingo/blob/main/pyproject.toml#L13-L19

So I think if we just change all scripts to run everything through that poetry project then I think all problems with the interdependency/having different pyproject.toml files should be gone for most users and developers, though I would still have to deal with those problems when publishing new versions of the packages

[sublime-coleslaw]

That's a good point, I hadn't considered that local dependencies would break publishing.

While I was trying to figure out a solution, I ran into a different problem. Running poetry build from the root librelingo directory fails with the error

Building librelingo (0.1.0)
  - Building sdist

No file/folder found for package librelingo

Is that normal or am I doing something wrong? When I run poetry install, poetry says something similar, so I assume the two are related. What's the normal process for building a dist package?

The current project could not be installed: No file/folder found for package librelingo
If you do not want to install the current project use --no-root

[sublime-coleslaw]

The two workarounds that immediately come to mind for me are:

1. switch build system to something like hatch/flit (requires moving away from poetry, would probably be very annoying)
2. create one big librelingo package instead of using multiple sub-packages (probably also annoying, but less so than switching build system)

[kantord]

That's a good point, I hadn't considered that local dependencies would break publishing.

While I was trying to figure out a solution, I ran into a different problem. Running poetry build from the root librelingo directory fails with the error

Building librelingo (0.1.0)
  - Building sdist

No file/folder found for package librelingo

Is that normal or am I doing something wrong? When I run poetry install, poetry says something similar, so I assume the two are related. What's the normal process for building a dist package?

The current project could not be installed: No file/folder found for package librelingo
If you do not want to install the current project use --no-root

the first problem, I think that is kinda to be expected because it's unclear what that build would really do. I guess it could build all packages all at once, but I think that is not a usecase that poetry supports, so I think that build command will not work.

the second problem I am not sure about, that might be some bug or a problem. I think that the root poetry project is not supposed to install a package, it's really only used for handling the virtual env for testing/running scripts in. so maybe this error needs to be suppressed

[kantord]

The two workarounds that immediately come to mind for me are:

1. switch build system to something like hatch/flit (requires moving away from poetry, would probably be very annoying)
2. create one big librelingo package instead of using multiple sub-packages (probably also annoying, but less so than switching build system)

I think that alternative 2) seems to be the most reasonable, I think that could simplify a lot of things, although it kinda makes the concept of a monorepo pointless.