Module / Package management - pip interface

[ebresie]

Presently as of 0.1, there is no ability to manage or identify Python modules/packages within a given environment and/or project.

This is issue will implement module / package functionality within the IDE.

[ebresie]

This may involve integration with package tools like:

• pip https://pypi.org/project/pip/
• pipenv https://realpython.com/pipenv-guide/

[ebresie]

As part of this, the Python Platform page has a "Module" tab which currently is not populated.

Will likely need to interface via python - pip list to obtain the currently installed modules for the given platform. The results of this will need to be populated in the list.

[ebresie]

For project specific module management, may need to leverage setuptool or equivalent project management to have dependencies available for use in the Python Project. See https://github.com/ebresie/python4nb/issues/20

[ebresie]

See https://pip.pypa.io/en/stable/cli/pip_list/

[ebresie]

Adjusting the scope of this to focus on providing a pip interface. This may further be expanded upon for other Module/Package Management based development which will be captured in a separate issue as applicable.

[ebresie]

As of v0.3.0, possible places in the code to focus on pip interfaces which includes

Python Platform - this is from the Tools...Python Platform contexts for a given Python Platform and it's applicable "Modules"

• PythonPackage - this class is to represent a python projects "python package file".
  -- Much of this code is commented placeholder code for getting PipDependenecies for the package.
  -- This interacts with PythonExecutionable.
  -- During PythonPlatformProvider method "detectPython" logic there is interfaces -- PythonSupport

Project Properties Library - this is used as part of the Python Project Properties - Library pane

• PythonLibraries
• PythonLibrariesPanel - is used in the python project properties Library contents (not to be confused with the "Platform's Module" pane. This may eventually call to other interfaces to poll for packages elsewhere. Some of this code is loosely based on NBPython code and has been commented out to reimplement within the Python4NB plugin. Some of the above-mentioned references may go away in favor of new refactored code,

LSP interface

• PythonLsp - this is where the Python Language Server interfaces is leverages. It starts up the python LSP server (a python thread) which listens and responses to interaction with the server. Not sure if there is necessarily any true need for pip interface but need to investigate further.

Option Interfaces - this is from Tools...Options...Python

• PythonOptions - this calls out to PythonUtils.getPip logic. This is leverage in PythonOptionValidator and PythonOptionsPanelController
• PythonOptionsValidator
• PythonOptionsPanel
• PythonOptionPanelController

General Interfaces - These are possible shared utilities classes for use in multiple contexts. I think some of this may still be for use in the Options context but need further investigation

• PythonUtils - has utility layer with some pip interfaces. This may be a good starting point to interface with pip
• ValidationUtils

[ebresie]

The getPip interface in use in Tools...Option...Python context I believe may have been used previously during logic derived from NBPython as it's called in that context, but the PythonOptionsPanel has nowhere to display any "libraries" as such. Here either need to add a pane to display libraries or look elsehwhere.

[ebresie]

I maybe mixing PythonLibraries and PythonPackages in similar intent. I may need to combine some of these or refactor some of this code in some way. Since PIP stands for "Pip Installs Python" or "PIP Installs Packages" I think "package" is more appropriate.

Trying to refactor any "Library" references to "PythonPackage" usage. There appears to be some Node type logic in the PythonPackage context which may be left over from code base.

[ebresie]

May want to consider Dependency management as part of the scope here. This may overlap with other tickets such as #42 which has some overlapping coverage with dependency management as well.

For example, dependencies could be captured in a requirements.txt or a setup.cfg or some other similar dependency management file.