[3pt] Document Thoth's requirement for dependencies to be in an index

[codificat]

Problem statement

As a Thoth user, I am frustrated because Thoth can not provide advise about my application software stack, because my Pipfile references modules that are not hosted in a package index (local modules, file / git references).

For example:

• Automatically raised Key error for 'src' Pipfile.lock member not having 'version' key in package_info dictionary. kebechet#860
• Thamos advise has problem with local packages thamos#728 (comment)

And if I run thamos advise and my Pipfile contains an editable install:

$ thamos advise
2022-05-19 13:50:37,067 [163181] WARNING  thamos: Development dependencies will not be considered during the resolution process - see https://thoth-station.ninja/j/no_dev
2022-05-19 13:50:37,067 [163181] INFO     thamos.lib: Using Pipenv files to manage dependencies located in '/home/pep/github/os-climate/aicoe-osc-demo'
2022-05-19 13:50:37,067 [163181] INFO     thamos.lib: Submitting Pipfile.lock as a base for user's stack scoring - see https://thoth-station.ninja/j/user_stack
2022-05-19 13:50:37,068 [163181] ERROR    thamos: Failed to load Pipfile (path: /home/pep/github/os-climate/aicoe-osc-demo/Pipfile: Package 'src' is editable local project instead of a package from a package index

and it is unclear to me why this is an ERROR and how to fix it.

High-level Goals

Documentation exists, clearly reachable within the Thoth documentation, that explains:

• why this is happening
• what are the alternatives and their implications
• how should I proceed so that Thoth can provide advice

Proposal description

Alternatives

Additional context

A blog post was published one year ago about this topic: https://developers.redhat.com/articles/2021/05/26/can-we-consider-editable-bad-practice

However, this is not part of Thoth's documentation.

Acceptance Criteria

Documentation in the Thoth website covers:

• the requirements that my dependency specifications must meet
• the reasoning behind these requirements
• alternative options and their consequences
• clear steps to help me meet the requirements
• pointers and references to learn more about it

And based on that documentation:

• create a follow-up issue so that entry points that fail due to unmet requirements provide links to the documentation about them

[codificat]

/sig user-experience
/triage accepted
/priority important-soon

[codificat]

Given that the content of the documentation is heavily tied to the guidance service, this is
/sig stack-guidance
more than
/remove-sig user-experience

[codificat]

/assign

[codificat]

A (relatively) related request is thoth-station/adviser#2275.

[sesheta]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[codificat]

/wg cnbi

[codificat]

/remove-lifecycle stale

[codificat]

This is delayed waiting for input from the alternative approaches and how they apply to a real-life use case, e.g. thoth-station/opendatahub-cnbi#14