Error thrown running `dream.py` on main branch `ModuleNotFoundError: No module named 'ldm'`

[vanakema]

When trying to run the dream.py file on the current main branch, I get the following error:

/content/stable-diffusion# pipenv run scripts/dream.py
Traceback (most recent call last):
  File "scripts/dream.py", line 12, in <module>
    import ldm.dream.readline
ModuleNotFoundError: No module named 'ldm'

Environment: Google Colab & Docker (WSL2 + GPU passthrough)
Python 3.8.13

The error that was outputted above came from the google colab environment on the main branch (removed line that checked out a specific tag).

I've been working in a docker container and thought maybe it had something to do with not using conda, but I tried the colab notebook in the Colab env, and removed the line to checkout the specific tag, and encountered the same error, so I am fairly certain it's an issue with the current branch rather than an env issue.

When I ran the same line on tags/release-1.09, it showed the initialization message

[lstein]

This seems to be a common problem when the initial install didn't complete for whatever reason. Recommended solutions are to run "conda env update -f environment.yaml" or "pip install -e ." If neither of these works, then the hack is to take dream.py out of the scripts directory, put it in the top-level stable-diffusion directory, and run it from there.

It's possible that something did get broken in the latest update, and I'd be interested in hearing from other Colab and Docker users whether this is a new problem that appeared. There have been so many updates over the past 48 hours (in a mostly good feature-adding way) that I wouldn't be surprised.

[vanakema]

I had previously tried pip install -e . in my docker container but it didn't help 😢
The fix did work for colab though.

I'll try my docker container on one of the existing releases

[vanakema]

I retried -e on my docker container just to make sure I didn't do something big dumb, but same result

[lstein]

Well, it got you 50% of the way there... Some other things to try: 1. Have you tried putting the full path to stable-diffusion in the environment variable PYTHONPATH? 2. Edit the file dream.py and put this at or near the top of the file: sys.path.append('/path/to/stable-diffusion') (replace with the actual path to the stable-diffusion directory) Let me know if you find a working solution. This has probably been the most elusive of bugs in the fork, and I wish I could get to the bottom of it. Lincoln

…

On Wed, Aug 31, 2022 at 11:16 PM Mark V ***@***.***> wrote: I retried -e on my docker container just to make sure I didn't do something big dumb, but same result — Reply to this email directly, view it on GitHub <#272 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA3EVKIWF2A26TPJUH6EEDV4AN2HANCNFSM6AAAAAAQB5MCAA> . You are receiving this because you commented.Message ID: ***@***.***>

-- *Lincoln Stein* Head, Adaptive Oncology, OICR Senior Principal Investigator, OICR Professor, Department of Molecular Genetics, University of Toronto Tel: 416-673-8514 Cell: 416-817-8240 ***@***.*** *E**xecutive Assistant* Michelle Xin Tel: 647-260-7927 ***@***.*** ***@***.***>* *Ontario Institute for Cancer Research* MaRS Centre, 661 University Avenue, Suite 510, Toronto, Ontario, Canada M5G 0A3 @OICR_news <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Foicr_news&data=04%7C01%7CMichelle.Xin%40oicr.on.ca%7C9fa8636ff38b4a60ff5a08d926dd2113%7C9df949f8a6eb419d9caa1f8c83db674f%7C0%7C0%7C637583553462287559%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PS9KzggzFoecbbt%2BZQyhkWkQo9D0hHiiujsbP7Idv4s%3D&reserved=0> | www.oicr.on.ca *Collaborate. Translate. Change lives.* This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.

[vanakema]

Using the latest release tag in my docker container allowed the initializing message to show in my docker container, but then it failed with ModuleNotFoundError: No module named 'clip' which is very strange too. I can see it in the src folder. I tried rerunning pip install -r requirements.txt but no dice. Tried adding the sd path to my PYTHONPATH but no luck either for the clip issue. Adding sys.path.append('/path/to/stable-diffusion') to the top of the dream.py didn't help with the clip issue.

Adding export PYTHONPATH="/app" helped me get it to show the initialization message on main! Progress!

Btw thanks for all your work on this. Very cool enhancements to the original repo

[vanakema]

Doing export PYTHONPATH="/app:/app/src" fixed the clip import issue!

[vanakema]

Hit the same issue with

Loading model from models/ldm/stable-diffusion-v1/model.ckpt
Traceback (most recent call last):
  File "scripts/dream.py", line 545, in <module>
    main()
  File "scripts/dream.py", line 91, in main
    t2i.load_model()
  File "/app/ldm/simplet2i.py", line 536, in load_model
    model = self._load_model_from_config(config, self.weights)
  File "/app/ldm/simplet2i.py", line 589, in _load_model_from_config
    model = instantiate_from_config(config.model)
  File "/app/ldm/util.py", line 89, in instantiate_from_config
    return get_obj_from_str(config['target'])(
  File "/app/ldm/util.py", line 99, in get_obj_from_str
    return getattr(importlib.import_module(module, package=None), cls)
  File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 843, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/app/ldm/models/diffusion/ddpm.py", line 39, in <module>
    from ldm.models.autoencoder import (
  File "/app/ldm/models/autoencoder.py", line 6, in <module>
    from taming.modules.vqvae.quantize import VectorQuantizer2 as VectorQuantizer
ModuleNotFoundError: No module named 'taming'

Had to add /app/src/taming-transformers to the PYTHONPATH too. This is such a weird bug

[tildebyte]

Something which should be automatically modifying the path isn't. Unfortunately, given the complexity of your environment, it's really hard to say what (candidates are: conda, pip, pipenv, colab itself... I don't really understand how docker is involved in this, but the any paths set in the container's Dockerfile might have an issue)

[vanakema]

Unfortunately, given the complexity of your environment, it's really hard to say what (candidates are: conda, pip, pipenv, colab itself... I don't really understand how docker is involved in this, but the any paths set in the container's Dockerfile might have an issue)

The environment isn't actually that complex. Not using conda and not using pipenv (that's part of why I use docker). Not using Colab; Colab was just a separate environment I tried running to see if it was an env issue.

I'll push to my fork later tonight to let you guys see the Dockerfile and what commands I run to use it.

[adamjgrant]

In case this helps anyone else, I resolved this on an M1 mac by just installing Anaconda from https://www.anaconda.com/

[vanakema]

In case this helps anyone else, I resolved this on an M1 mac by just installing Anaconda from https://www.anaconda.com/

Yeah that makes some sense, I had a hunch that it had something to do with the way that modules in Anaconda environments are handled. The reason I'm still confused is because the colab notebook just uses pipenv, not conda, and it works fine after running 'pip install -e .'

[tildebyte]

I use pip-only on baremetal Win 11/RTX 2070 8G VRAM in a pew environment (which under the covers is a standard virtualenv) - I have no issues.

@vanakema; Can you explain your exact environment? You've mentioned Google Colab, Docker, WSL2, GPU passthrough, conda, pip... What is your host environment (OS & ver, GPU & VRAM)? In which exact environment are you trying to actually run the 'dream' script?

[vanakema]

Sure. It's just what I said in my first post, though I understand the confusion of the two separate environments. Sorry for the confusion.

Primary environment tested in:
Windows 10, 2080ti 12gb -> Docker for Windows w/ WSL2 integration and GPU passthrough -> Ubuntu Docker container
No special python environment manager, just straight pip.
Python 3.8.13
Pip 22.2.2

Secondary environment tested in as a sanity check:
Google Colab Free

I am not using conda. I mentioned not using conda because it's specifically mentioned in the readme, so I wanted to call out that the lack of using conda was a suspect of mine, but the Colab environment (and yours) proves otherwise.

However, ultimately the host env should have no affect on python module import issues in a docker container

[vanakema]

Let me know if there's any other pieces of my env you want more details on.