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

[Feature Request]: Extentions can't use A1111 modules in correct way #15697

Open
1 task done
shsotoudegan opened this issue May 3, 2024 · 2 comments
Open
1 task done
Labels
enhancement New feature or request

Comments

@shsotoudegan
Copy link

Is there an existing issue for this?

  • I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

There is a complete conversation in Mikubill/sd-webui-controlnet#2836 issue and Mikubill/sd-webui-controlnet#2839 pull request on ControlNet repo. Implementation of launch_utils.run_extension_installer can be better. but that can effect All other extensions installation.

def run_extension_installer(extension_dir):
path_installer = os.path.join(extension_dir, "install.py")
if not os.path.isfile(path_installer):
return
try:
env = os.environ.copy()
env['PYTHONPATH'] = f"{os.path.abspath('.')}{os.pathsep}{env.get('PYTHONPATH', '')}"
stdout = run(f'"{python}" "{path_installer}"', errdesc=f"Error running install.py for extension {extension_dir}", custom_env=env).strip()
if stdout:
print(stdout)
except Exception as e:
errors.report(str(e))

I know that relative import beyond the top-level package in python not allowed. but I think with a better implementation of this function (which I don't know how to do that) we can help extension contributors think about something else.

Proposed workflow

  1. change implementation of run_extension_installer for help extensions to use A1111 modules in better way with out relative import beyond the top-level package problem.

Additional information

this can help extensions for better contribution to project.

@w-e-w
Copy link
Collaborator

w-e-w commented May 4, 2024

my guess is that your current work directory is not at webui root

for a test modify

env['PYTHONPATH'] = f"{os.path.abspath('.')}{os.pathsep}{env.get('PYTHONPATH', '')}"

to

env['PYTHONPATH'] = f"{os.path.dirname(os.path.dirname(__file__))}{os.pathsep}{env.get('PYTHONPATH', '')}"

os.path.abspath('.') -> os.path.dirname(os.path.dirname(__file__))

and if it's this case I think this is more of a user instance configuration error


webui is build on the assumption that the cwd is webui root
os.path.abspath('.')is the cwd and will be prepend toPYTHONPATH` when running install.py
this will allow install.py to access webui scripts like importing launch
but if you cwd is not webui root, import launch will fail
the the above fix for you this is most likely what's happening

if this is fixed is applied they might still be other issues as they might be other places in code that makes the assumption that cwd is webui root

@shsotoudegan
Copy link
Author

my guess is that your current work directory is not at webui root

for a test modify

env['PYTHONPATH'] = f"{os.path.abspath('.')}{os.pathsep}{env.get('PYTHONPATH', '')}"

to

env['PYTHONPATH'] = f"{os.path.dirname(os.path.dirname(__file__))}{os.pathsep}{env.get('PYTHONPATH', '')}"

os.path.abspath('.') -> os.path.dirname(os.path.dirname(__file__))

and if it's this case I think this is more of a user instance configuration error

webui is build on the assumption that the cwd is webui root os.path.abspath('.')is the cwd and will be prepend toPYTHONPATH` when running install.py this will allow install.py to access webui scripts like importing launch but if you cwd is not webui root, import launch will fail the the above fix for you this is most likely what's happening

if this is fixed is applied they might still be other issues as they might be other places in code that makes the assumption that cwd is webui root

Thanks for you're recommend @w-e-w . I created a pull request #15704 for this issue.

In some cases, for example when A1111 uses in dependencies of another project ( for example get access to A1111 by API in replicate/cog) user isn't in A1111 root directory. User uses A1111 from another project root and needs to install some extensions that uses A1111 modules. that cases that extensions like ControlNet fail in installation process.

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

No branches or pull requests

2 participants