Fix environment-dev.yml

[nenb]

When I create the mamba environment via mamba env create --file environment-dev.yml and then install the project dependencies via pyproject.toml, ipython is broken for me.

Traceback:

Traceback (most recent call last):
  File "/Users/nenb/miniforge3/envs/ragna-dev/bin/ipython", line 8, in <module>
    sys.exit(start_ipython())
  File "/Users/nenb/miniforge3/envs/ragna-dev/lib/python3.9/site-packages/IPython/__init__.py", line 129, in start_ipython
    return launch_new_instance(argv=argv, **kwargs)
  File "/Users/nenb/miniforge3/envs/ragna-dev/lib/python3.9/site-packages/traitlets/config/application.py", line 1075, in launch_instance
    app.start()
  File "/Users/nenb/miniforge3/envs/ragna-dev/lib/python3.9/site-packages/IPython/terminal/ipapp.py", line 317, in start
    self.shell.mainloop()
  File "/Users/nenb/miniforge3/envs/ragna-dev/lib/python3.9/site-packages/IPython/terminal/interactiveshell.py", line 887, in mainloop
    self.interact()
  File "/Users/nenb/miniforge3/envs/ragna-dev/lib/python3.9/site-packages/IPython/terminal/interactiveshell.py", line 872, in interact
    code = self.prompt_for_code()
  File "/Users/nenb/miniforge3/envs/ragna-dev/lib/python3.9/site-packages/IPython/terminal/interactiveshell.py", line 813, in prompt_for_code
    text = self.pt_app.prompt(
TypeError: prompt() got an unexpected keyword argument 'inputhook'

If you suspect this is an IPython 8.18.0 bug, please report it at:
    https://github.com/ipython/ipython/issues
or send an email to the mailing list at ipython-dev@python.org

You can print a more detailed traceback right now with "%tb", or use "%debug"
to interactively debug it.

My understanding is this error is related to the fact that ipython (installed via jupyter by mamba) has a lower pin on prompt-toolkit of 3.0.41, whereas questionary (installed by pip) has an upper pin of 3.0.36. A conflict arises because pip is not fully aware of what mamba has installed, and so ipython is broken for me in the current environment.

The quickest solution that I can think of is to remove jupyter (and hence ipython) from the mamba environment, and instead install manually with pip at the very end of the process eg python -m pip install 'prompt_toolkit>=2.0,<=3.0.36' 'ipython<=8.16'.

Perhaps there is a cleaner solution in which case I will close this PR. If not, I would like to consider merging it, as ipython is a useful tool when prototyping in the terminal.

[ndmlny-qs]

I ran into the same issue. My work-around was to pin ipython = 8.18.1 and to use jupyterlab 4. Try out the following environment file and see if that fixes the issue. I haven't tried it out in over a week, so the below file may be out of date.

name: ragna-dev
channels:
  - conda-forge
dependencies:
  - python =3.9
  - pip
  - pip:
      - jupyterlab >=4.0.10
      - ipython ==8.18.1
      - python-dotenv
      - boto3
      - pytest >=6
      - pytest-mock
      - mypy ==1.6.1
      - pre-commit
      - types-aiofiles
      - sqlalchemy-stubs
      # documentation
      - mkdocs
      - mkdocs-material
      - mkdocstrings[python]
      - mkdocs-gen-files
      - material-pl

[nenb]

@ndmlny-qs I had a quick attempt (with the comment that I think you forgot to paste in a couple of dependencies at the bottom of your .yml) but unfortunately it is still breaking for me. pip gives a traceback which includes

...
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
ipython 8.18.1 requires prompt-toolkit<3.1.0,>=3.0.41, but you have prompt-toolkit 3.0.36 which is incompatible.
...

and ultimately ipython gives the same traceback as above.

I have an Apple Silicon machine, which possibly makes a difference when doing all the package resolution - I don't know, I haven't looked into it.

Ultimately the only way I have got round this so far is manually installing ipython and prompt_toolkit at the very end of the process (see previous comment), as this was the only way that I could guarantee that they would be compatible with each other.

(Thanks for the support. Ideally I would prefer a change to the .yml like you have done if possible, but I don't want to spend too much time on it either...)

[pmeier]

I think the better fix would be to drop the "pip" installation from the environment file and just have a requirements-dev.txt file separately. That way the pip resolver can do its thing.

That being said, I want to eliminate notebooks from the repo and in turn the jupyter dependency anyway. See #89. If that is the only blocker, I'm also ok with removing it from the requirements already and move on. Up to you.