fix(convert-hf-to-gguf): requires einops for InternLM2ForCausalLM models

[Nold360]

small fix for container images, which will currently fail with:

Traceback (most recent call last):
  File "/app/convert-hf-to-gguf.py", line 1934, in <module>
gguf: This GGUF file is for Little Endian only
Set model parameters
Set model tokenizer
InternLM2 convert token 'b'\x00'' to '🐉'!
gguf: Setting special token type bos to 1
gguf: Setting special token type eos to 2
gguf: Setting special token type pad to 2
gguf: Setting chat_template to {{ bos_token }}{% for message in messages %}{{'<|im_start|>' + message['role'] + '
' + message['content'] + '<|im_end|>' + '
'}}{% endfor %}{% if add_generation_prompt %}{{ '<|im_start|>assistant
' }}{% endif %}
Exporting model to '/workspace/input/ggml-model-f16.gguf'
    main()
  File "/app/convert-hf-to-gguf.py", line 1928, in main
    model_instance.write()
  File "/app/convert-hf-to-gguf.py", line 152, in write
    self.write_tensors()
  File "/app/convert-hf-to-gguf.py", line 1612, in write_tensors
    from einops import rearrange
ModuleNotFoundError: No module named 'einops'
Traceback (most recent call last):
  File "/app/convert.py", line 1483, in <module>

used 0.7.0 cause it's the current release.

[cebtenzzre]

@crasm Were these files meant to contain required dependencies, or also include optional dependencies? In the latter case, this PR is a step in the right direction, but we also need to add tiktoken for Qwen models.

[Nold360]

@crasm Were these files meant to contain required dependencies, or also include optional dependencies? In the latter case, this PR is a step in the right direction, but we also need to add tiktoken for Qwen models.

good point. imho they are so tiny compared to the rest, that we could just add them before building workarounds for containers

[crasm]

@crasm Were these files meant to contain required dependencies, or also include optional dependencies? In the latter case, this PR is a step in the right direction, but we also need to add tiktoken for Qwen models.

It's supposed to be for all dependencies.

The check-requirements.sh script and workflow were intended to prevent these kinds of PRs from being necessary, by forcing all dependencies to be declared in the requirements.txt files.

Has the workflow check been failing consistently from running out of space, like in the other PR you tagged me? (edit: yes) That could explain why these are slipping though.

[crasm]

Maybe it'd be better to forgo the complexity I introduced in the requirements.txt. We could just do #5745 and declare each script's optional dependencies in the pyproject.toml.

[cebtenzzre]

This PR is an improvement, and is fine by me until we have a better solution.

[crasm]

Looks good. I'll investigate the disk space issue, which I suspect is a configuration issue rather than an actual resource limitation.

[crasm]

I'm trying to figure out how to catch any more of these implicit dependencies to prevent more gotchas.

@cebtenzzre Is it normal to have import statements embedded in various places in python scripts? That seems crazy to me coming from other languages.

[cebtenzzre]

Is it normal to have import statements embedded in various places in python scripts? That seems crazy to me coming from other languages.

Yep, this is how optional dependencies are typically implemented in python - you import them lazily so they only matter if the code that needs them is run. With a venv and a type checker like mypy, it's not hard to detect if these dependencies are missing when they shouldn't be - it will complain with import-not-found.