Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for editable pip installs #36

Merged
merged 3 commits into from
Jun 19, 2024
Merged

Add support for editable pip installs #36

merged 3 commits into from
Jun 19, 2024

Conversation

jaimergp
Copy link
Member

Closes #35

@dholth
Copy link
Contributor

dholth commented Jun 18, 2024

conda/conda-build#5380 is a very rough outline of how I would do it using pypa/build. Especially it gives us the opportunity to install the build system (flit_core, hatch, ...) with our preferred installer instead of necessarily using pip.

@jaimergp
Copy link
Member Author

Isn't pip installing the build system on its own? We have the concept here of "backend", which you can use with grayskull and pip. But yea it's not super perfect. I'm not sure how much I'd like to reimplement from scratch instead of delegating to pip (or uv in the future).

@jaimergp
Copy link
Member Author

Ah, I see what you mean, installing build-system.requires with conda in... a temporary environment? 🤔

@dholth
Copy link
Contributor

dholth commented Jun 18, 2024

In the draft PR I've linked perhaps you can begin to imagine how we could avoid almost all pip invocation, especially if we include our own wheel installer (or https://github.com/zuzukin/whl2conda to convert to .conda and then install)
pypa/build makes the wheel by delegating to each package's build system, setuptools, flit, etc.
Our preferred installer takes care of the environment, dependencies.
Functions from packaging handle the full PEP 508 Python dependency specifications https://packaging.pypa.io/en/stable/markers.html

In "no build isolation" mode, which is what the draft PR halfheartedly implements, you would install the build system "flit_core" or whatever into the current or target conda environment. If it was more like conda-build a temporary conda environment would be used. The build system could also be installed into a temporary directory that is added to PYTHONPATH, or it is allowed that the build system can come from the tree as in when flit builds flit.

Now make it recursive! Imagine an almost seamless experience.

@jaimergp
Copy link
Member Author

Ok, I see, I like that! Added #37 to track these suggestions. Let's consider this PR a barebones prototype for now.

@jaimergp jaimergp merged commit 590900a into main Jun 19, 2024
16 checks passed
@jaimergp jaimergp deleted the editable branch June 19, 2024 11:41
@jezdez
Copy link
Member

jezdez commented Jun 20, 2024

@jaimergp @dholth Hold on, why would we encourage creating wheel files instead of conda files? There isn't a conda specific platform tag, so I have a hard time seeing a way to differentiate the files from regular Python wheel builds.

@dholth
Copy link
Contributor

dholth commented Jun 20, 2024

I'm talking about the ephemeral "installs a .pth to effect an editable install" wheels from https://peps.python.org/pep-0660/ . We would install and then call into the build system, it spits out that wheel.

We would probably pip install the ephemeral wheel, but it might be interesting to turn it into a conda package and install that way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement pip's editable installation method for condaverse
3 participants