WIP: pure poetry translator #397
Conversation
phaer
force-pushed
the
poetry-translator
branch
from
37e86fa to
3b0953b
Compare
pypi-sdist expects pname and version parameters, lets reflect that in the schema.
DavHau
force-pushed
the
poetry-translator
branch
from
3b0953b to
31b0b52
Compare
| @@ -132,7 +133,22 @@ | |||
| "properties": { | |||
| "hash": { "type": "string" }, | |||
| "type": { "type": "string" }, | |||
| "dir": { "type": "string" } | |||
| "pname": { "type": "string" }, | |||
| "version": { "type": "string" } | |||
There was a problem hiding this comment.
There is no need to store the version. The version is already contained in the keys of the attrset. The framework will still pass it to the fetcher despite not being explicitly present as a field.
| decompressed = true; | ||
| # generic fields | ||
| _generic = { | ||
| # TODO: specify the default package name |
There was a problem hiding this comment.
Those TODOs are already resolved and can be removed
| @@ -40,40 +40,40 @@ | |||
| package = produceDerivation defaultPackageName (buildFunc { | |||
| name = defaultPackageName; | |||
| src = getSource defaultPackageName defaultPackageVersion; | |||
| format = "setuptools"; | |||
| format = "other"; | |||
There was a problem hiding this comment.
@chaoflow Maybe the format other could be the right choice for your branch as well. Maybe you guys could review each others builder changes. It would be good if we can have a generic builder that works for both poetry and requirements based projects projects.
There was a problem hiding this comment.
Yes, with pleasure! Maybe it would be useful to do a call or at least open up a pad to collect requirements in a table or so and try to see where those overlap? @chaoflow
I quickly experimented with just building a wheel for poetry projects a well and install that one in an extra step. That currently fails if the project being packaged has a dependency which is also (transitively) depended on by buildInputs, because that it tries to uninstall the former one first. I think going that route should allow us to ship most of the code? But not yet sure how to solve that
There was a problem hiding this comment.
Sure, let's have a call. How about we use the dream2nix weekly tomorrow (Tuesday) at 14:00 UTC for this?
There was a problem hiding this comment.
Ah right, you do weekly meetings for this project :) Sounds good, will be there!
|
@phaer I added wheel to the nativeBuildInputs. All tests are green now. I will merge this already, so we have something that works and not having the python branches diverge too much. For further changes please open a new branch. Thanks for your amazing work so far! |
|
@DavHau Thanks! Not sure whether its of much use right now, but I guess there's not much harm done as long as we don't really promote it in the docs. Definitely plan to continue working on this, but can't really give a schedule |
This arg was inadvertently added to pip install in nix-community#397, which breaks transitive dependencies on the packages we custom-install, like setuptools and wheel. Per @phaer, it wasn't supposed to be there and has already been removed in the next set of larger changes, but this should fix those transitive dependencies in the meantime.
This arg was inadvertently added to pip install in nix-community#397; it breaks transitive dependencies on the packages we custom-install, like setuptools and wheel. Per @phaer, it wasn't supposed to be there and has already been removed in the next set of larger changes, but this should fix those transitive dependencies in the meantime.
No description provided.