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

[question] A way to install non-code file into "site-packages" itself #349

Closed
kshpytsya opened this issue Jun 3, 2020 · 2 comments
Closed

Comments

@kshpytsya
Copy link

I am looking for a way to use flit to create a package that would install a file into "site-packages" directory proper (i.e. not into some its sub-directory). I need this to be able to install a .pth file, as discussed here.

BTW, I wasn't able to get the recipe from that post working, but instead came up with the following:

setup.py

from setuptools import setup

setup(
    name="xxx1",
    package_dir={"": "src"},
    py_modules=["xxx1"],
    data_files=[("/", ["src/xxx1.pth"])],
)

src/xxx1.pth

import xxx1

src/xxx1.py

print("xxx1 imported")

According to this, my approach uses an undefined behavior. Moreover, it works only if installing from a wheel, so e.g. venv/bin/pip install . fails with an understandable error: could not create '/xxx1.pth': Permission denied.

I have seen this but as far as I understand, it only allows files inside package directories.

I am perfectly ok with having src/xxx1/__init__.py instead of src/xxx1.py (BTW, thanks for finally making the src layout possible) but I do need a way to install .../site-packages/xxx1.pth file.

@takluyver
Copy link
Member

Sorry, that's not supported, and not likely to be supported. Flit is very much aimed at the 80% in the 80/20 rule, so if you want to do something unusual, you'll probably need to use another tool.

(I'm also especially disinclined to support this use case, because I think the executable .pth files are a misfeature. There are a couple of legitimate use cases - like coverage measurements in subprocesses - that can't currently be done any other way, but I still don't like them.)

@kshpytsya
Copy link
Author

Kind thanks for your prompt reply. I suppose I will stick to setup.py for this particular package. Should you be curious, this is about addition of plugin mechanism to a certain major library, authors of which I believe would not want to include the feature upstream or it would take ages to come up with exact design that would satisfy everyone.

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

No branches or pull requests

2 participants