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 test-invoke-pip.yml #1521

Merged
merged 55 commits into from
Nov 25, 2022
Merged

add test-invoke-pip.yml #1521

merged 55 commits into from
Nov 25, 2022

Conversation

mauwii
Copy link
Contributor

@mauwii mauwii commented Nov 20, 2022

this workflow is similar to the conda test workflow, but instead is using pip to install requirements. It is testing

  • requirements-lin-cuda.txt
  • requirements-lin-amd.txt
  • requirements-mac-mps-cpu.txt

with Python 3.9 and 3.10.

IMPORTANT

this removes -e .from those 3 requirement files (imho should be removed from the others as well). So the workflow now is to install requirements, and afterwards pip install -e .

@mauwii mauwii marked this pull request as draft November 20, 2022 12:07
since it requires to have torch already installed
also restore origin requirements-base.txt after suc. test in my fork
@mauwii mauwii marked this pull request as ready for review November 20, 2022 12:24
@mauwii mauwii requested a review from lstein November 20, 2022 12:24
@mauwii
Copy link
Contributor Author

mauwii commented Nov 20, 2022

This comment is obsolete now 🙈

# IMPORTANT

This removes the `requirements-base.txt` from some requirements files (only the ones I can test here and local, but I suppose it should be removed from the others as well).

For me the installation was also not working locally with the `requirements-base.txt` included in the `requirements.txt` (same error as in workflow, `torch` needs to be installed first), which makes me think that this only worked on system with preinstalled / shared `torch` package.

@keturn
Copy link
Contributor

keturn commented Nov 21, 2022

I don't know all the ins and outs of pip dependency resolution, but the concern I would have about splitting it into multiple commands is whether or not it resolves things the same way when it's not given the dependency tree all at once. Especially when modifiers like --pre and --extra-index-url are involved.

The error looks like the one this was intended to fix: XPixelGroup/BasicSR#514

which is tagged as if it were released in basicsr 1.4.2. And yet, the logs here show this using 1.4.2 and encountering that error on line 8 of setup.py. The line removed by that PR???

@mauwii
Copy link
Contributor Author

mauwii commented Nov 21, 2022

I am not sure if I can follow you. The error appears for example here, which was when installing basicsr-1.4.1.tar.gz. This was exactly the same error I got when doing a pip install --prefer-binary -r requirements.txt (where requirements.txt was a symlink to environments-and-requirements/requirements-mac-mps-cpu.txt.

But yes, I am with you, if possible it would be better to have the requirements-base.txt called from within the environments requirements*.txt

@keturn
Copy link
Contributor

keturn commented Nov 21, 2022

Wait, how did it end up with 1.4.1? We have a requirement for 1.4.2, that's what it downloaded... oh.

INFO: pip is looking at multiple versions of realesrgan to determine which version is compatible with other requirements. This could take a while.
Collecting realesrgan
  Downloading realesrgan-0.2.9-py3-none-any.whl (26 kB)
  Downloading realesrgan-0.2.8-py3-none-any.whl (25 kB)
  Downloading realesrgan-0.2.7-py3-none-any.whl (26 kB)
  Downloading realesrgan-0.2.6-py3-none-any.whl (26 kB)
  Downloading realesrgan-0.2.5.0-py3-none-any.whl (25 kB)
Collecting basicsr>=1.3.3.11
  Downloading basicsr-1.4.1.tar.gz (171 kB)

[See the pip manual on Backtracking for why it's downloading so many versions.]

So initially pip did get us the right version of basicsr, but then something has it going back a bunch of versions of realesrgan, until it finally goes back so far that it finds a realesrgan requiring the broken basicsr. What a mess!

requirements-base currently doesn't specify a version dependency for realesrgan at all. Can we add one to prevent it from going back that far?

It'll likely break, because there was some reason it thought it wouldn't be able to use the current version of realesrgan in the first place, but at least it will tell us what that reason is and maybe that's something we can fix.

add `basicsr>=1.4.2` to requirements-base.txt
remove second installation step
@mauwii mauwii added the CI-CD Continuous integration / Continuous delivery label Nov 21, 2022
@mauwii mauwii self-assigned this Nov 21, 2022
@mauwii
Copy link
Contributor Author

mauwii commented Nov 21, 2022

Very nice finding @keturn, now we get the next error:

error: [Errno 2] No such file or directory: '/home/runner/work/InvokeAI/InvokeAI/scripts/load_models.py'

@mauwii
Copy link
Contributor Author

mauwii commented Nov 21, 2022

When I replace realesrgan with git+https://github.com/invoke-ai/Real-ESRGAN.git#egg=realesrgan, I get this error (which at least points out where the broken basicsr dependencie comes from):

The conflict is caused by:
    The user requested basicsr>=1.4.2
    gfpgan 1.3.8 depends on basicsr==1.4.1

@mauwii
Copy link
Contributor Author

mauwii commented Nov 21, 2022

informed @lstein that I need information about how to run preload_models.py non interactive

@lstein
Copy link
Collaborator

lstein commented Nov 21, 2022

Is preload_models.py --no-interactive not working?

or rather, I think you may be asking for all the options to be set on the command line, like preload_models.py --output_dir=/foo/bar/outputs --models_dir=/foo/bar/models --configs_dir=/etc/configs ?? That's a good idea.

@lstein
Copy link
Collaborator

lstein commented Nov 21, 2022

When I replace realesrgan with git+https://github.com/invoke-ai/Real-ESRGAN.git#egg=realesrgan, I get this error (which at least points out where the broken basicsr dependencie comes from):


The conflict is caused by:

    The user requested basicsr>=1.4.2

    gfpgan 1.3.8 depends on basicsr==1.4.1

basicsr-1.4.2 fails to load on Windows computers. Starting out with a new venv or conda environment, pip install basicsr==1.4.2 seems to work ok, but then python -mbasicsr gets you a module not found error. 1.4.1 works fine.

This is why the requirements in realesrgan and gfpgan were downgraded to use 1.4.1.

Copy link
Collaborator

@lstein lstein left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, but I think @tildebyte should check.

@lstein lstein requested a review from tildebyte November 22, 2022 13:32
@lstein
Copy link
Collaborator

lstein commented Nov 23, 2022

@mauwii is this ready for a merge, and will it fix the current CI errors?

Copy link
Collaborator

@lstein lstein left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is ugly, but there are now three scripts that call the same codebase: preload_models.py, load_models.py, and configure_invokeai.py. I really only want to have the last one, but I don't want to alter the CI files without @mauwii 's blessing.

@mauwii mauwii mentioned this pull request Nov 24, 2022
@lstein
Copy link
Collaborator

lstein commented Nov 24, 2022

I'm getting the following dependency error after running pip install -r requirements.txt; pip install -e .:

Traceback (most recent call last):������������������������������������������������������������������������������������������������� 
  File "/home/lstein/.local/bin/invoke.py", line 4, in <module>�������������������������������������������������������������������� 
    __import__('pkg_resources').require('InvokeAI==2.1.4')������������������������������������������������������������������������� 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3254, in <module>������������������������������������������ 
    def _initialize_master_working_set():������������������������������������������������������������������������������������������ 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3237, in _call_aside��������������������������������������� 
    f(*args, **kwargs)������������������������������������������������������������������������������������������������������������� 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3266, in _initialize_master_working_set�������������������� 
    working_set = WorkingSet._build_master()��������������������������������������������������������������������������������������� 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 586, in _build_master�������������������������������������� 
    return cls._build_from_requirements(__requires__)������������������������������������������������������������������������������ 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 599, in _build_from_requirements��������������������������� 
    dists = ws.resolve(reqs, Environment())���������������������������������������������������������������������������������������� 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 792, in resolve�������������������������������������������� 
    raise VersionConflict(dist, req).with_context(dependent_req)������������������������������������������������������������������� 
pkg_resources.ContextualVersionConflict: (numpy 1.17.4 (/usr/lib/python3/dist-packages), Requirement.parse('numpy<1.26.0,>=1.18.5'), {'scipy'})

@mauwii
Copy link
Contributor Author

mauwii commented Nov 24, 2022

Are you using a clean environment? I mean the runners work to do the installation, so I doubt that there is any requirements error at all ....

@mauwii
Copy link
Contributor Author

mauwii commented Nov 24, 2022

And the runners succeed even with python 3.9 and python 3.10 xD

@mauwii
Copy link
Contributor Author

mauwii commented Nov 24, 2022

mostly suspiccious to me is this /usr/lib/python3/dist-packages/pkg_resources/__init__.py

when you are using a clean and new .venv, this should be the python3 path to your venv and i doubt that you created this in /usr/lib/ 🤔

Also strange is from where the numpy 1.17.4 should be 🙈

@mauwii mauwii merged commit 2433cc3 into development Nov 25, 2022
@mauwii mauwii deleted the add-test-invoke-pip-workflow branch November 25, 2022 00:24
@Vargol
Copy link
Contributor

Vargol commented Nov 26, 2022

IMPORTANT

this removes -e .from those 3 requirement files (imho should be removed from the others as well). So the workflow now is to install requirements, and afterwards pip install -e .

I go away for a few days...

Why was this done, pip install -r requirements....txt was successfully installing a working InvokeAi before this change.

@mauwii
Copy link
Contributor Author

mauwii commented Nov 26, 2022

For me on mac with M1 it didn't, neither for lstein, neither for the Runners.... So it was implemented to fix the Installation and it was discussed here and in discord. But nobody would stop you from implementing -e . back in the requirements and make it work 😉

@Vargol
Copy link
Contributor

Vargol commented Nov 26, 2022

For me on mac with M1 it didn't, neither for lstein, neither for the Runners.... So it was implemented to fix the Installation and it was discussed here and in discord. But nobody would stop you from implementing -e . back in the requirements and make it work 😉

So basically your saying you broke the pip install cos the conda install is broken ???

I'd love to fix it but conda is not getting anywhere near any computer I have to use python on.

@mauwii
Copy link
Contributor Author

mauwii commented Nov 26, 2022

The Conda fix was implemented after the pip fix and has nothing to do with the pip fix.

Maybe you should re-read what I wrote, which was speaking about the pip install which you mentioned...

@keturn
Copy link
Contributor

keturn commented Nov 26, 2022

because the pip install was broken. You can see this PR went through a lot of runs trying to find something that worked: https://github.com/invoke-ai/InvokeAI/actions/workflows/test-invoke-pip.yml?query=branch%3Aadd-test-invoke-pip-workflow+event%3Apull_request

@Vargol
Copy link
Contributor

Vargol commented Nov 26, 2022

I don't know when it doesn't work for the guys I've been using it right from the beginning.

@Vargol
Copy link
Contributor

Vargol commented Nov 26, 2022

I wonder if its because you took out the prefer binary option

@mauwii
Copy link
Contributor Author

mauwii commented Nov 26, 2022

So I guess you did not try a Installation from a clean venv, which indeed did not work. I did not spend hours of my life to fix something which is not broken, just for fun or to break it for everybody....

I wonder if its because you took out the prefer binary option

just take a look at the history, there are more than enough failing runs where you could look at ....

@Vargol
Copy link
Contributor

Vargol commented Nov 26, 2022

Sorry, I know nothing about Github actions would know where to start

@Vargol
Copy link
Contributor

Vargol commented Nov 26, 2022

Just edited the -e . back in on my own machine and i the pip went without issue.

python -m venv InvokeAIPip
cd InvokeAIPip
. ./bin/activate
git clone https://github.com/invoke-ai/InvokeAI.git
cd InvokeAI
git switch development
ln -sf environments-and-requirements/requirements-mac-mps-cpu.txt .

edit equirements-mac-mps-cpu.txt

pip install --prefer-binary -r requirements-mac-mps-cpu.txt
pip install -e .

@mauwii
Copy link
Contributor Author

mauwii commented Nov 26, 2022

Why do you do a pip install -e . when you have it edited back into the requirements?

I would suggest you open a PR if it is working to install now with -e . in the requirements. as I say I was not the only person who was affected with problems, also the runners didn't manage to install, that is all I have to say here ....

@Vargol
Copy link
Contributor

Vargol commented Nov 26, 2022

vBecause I clumsily copied an extra line from the script I used, the had a exit where I did the edit.
I didn't do the -e . install

% cat create_sd_stop.sh
set -x
python -m venv InvokeAIPip
cd InvokeAIPip
. ./bin/activate
git clone https://github.com/invoke-ai/InvokeAI.git
cd InvokeAI
git switch development
ln -sf environments-and-requirements/requirements-mac-mps-cpu.txt .
exit <-------
pip install --prefer-binary -r requirements-mac-mps-cpu.txt
pip install -e .
export PYTORCH_ENABLE_MPS_FALLBACK=1
#python scripts/preload_models.py --no-interactive
cp configs/models.yaml.example configs/models.yaml
cp ../../preflight_prompts.txt .
cp ../../curly.png .
cp ../../Lincoln-and-Parrot-512* .

1185 ./create_sd_stop.sh
1186 vi InvokeAIPip/InvokeAI/requirements-mac-mps-cpu.txt
1187 deactivate
1188 cd InvokeAIPip
1189 . bin/activate
1190 cd InvokeAI
1191 cat ../../create_sd_stop.sh
1192 pip install --prefer-binary -r requirements-mac-mps-cpu.txt
1193 cat ../../create_sd_stop.sh

@Vargol
Copy link
Contributor

Vargol commented Nov 26, 2022

#1570 raised

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI-CD Continuous integration / Continuous delivery
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants