Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
A compromise exists between automatically inferring package names (unreliable and potentially dangerous) and writing out an explicit separate requirements.txt file: script-running tools such as pip...
Answer
#3: Post edited
by
Karl Knechtel
·
2023-08-02T04:33:38Z (over 1 year ago)
- A compromise exists between automatically inferring package names (unreliable and potentially dangerous) and writing out an explicit separate `requirements.txt` file: script-running tools such as [`pip-run`](https://pypi.org/project/pip-run/) may offer the ability to parse requirements declared explicitly within the source file itself, and also allow specifying dependencies explicitly on the command line. Above and beyond managing dependencies, tools like this are designed to provide an isolated environment for the script (by automatically creating a virtual environment) - among other things, this means an error in the dependencies won't mess up your existing environment.
- When the script is your own code, then, it's easy to leave a note about dependencies that won't require *later remembering* that e.g. up-to-date versions of `PIL` need to be provided by `pip install pillow` instead. For others' code, at least there is a simpler way for others to communicate the *exact* requirements without distributing a separate file.
- The proposed [PEP 722](https://pep-previews--3210.org.readthedocs.build/pep-0722/) (currently being heavily discussed [on the Python Discourse forum](https://discuss.python.org/t/_/29905)) is an attempt to standardize a format for such metadata, so that it can become a target for more tools (note that these would *not* be necessary for packaging!) going forward. According to the author of the PEP, [`pipx`](https://pypi.org/project/pipx/) also has support for this feature implemented; but as far as I can tell, this refers to a development version not yet released.
Speaking of which, the discussion for the PEP just pointed me at another tool that seems reasonably fit for purpose, and much more lightweight than the above script-runners: [viv](https://github.com/daylinmorgan/viv). The model here is that scripts can explicitly register their dependencies by importing `viv` and telling it to `.use` a third-party package (identified by a string name).
- A compromise exists between automatically inferring package names (unreliable and potentially dangerous) and writing out an explicit separate `requirements.txt` file: script-running tools such as [`pip-run`](https://pypi.org/project/pip-run/) may offer the ability to parse requirements declared explicitly within the source file itself, and also allow specifying dependencies explicitly on the command line. Above and beyond managing dependencies, tools like this are designed to provide an isolated environment for the script (by automatically creating a virtual environment) - among other things, this means an error in the dependencies won't mess up your existing environment.
- When the script is your own code, then, it's easy to leave a note about dependencies that won't require *later remembering* that e.g. up-to-date versions of `PIL` need to be provided by `pip install pillow` instead. For others' code, at least there is a simpler way for others to communicate the *exact* requirements without distributing a separate file.
- The proposed [PEP 722](https://pep-previews--3210.org.readthedocs.build/pep-0722/) (currently being heavily discussed [on the Python Discourse forum](https://discuss.python.org/t/_/29905)) is an attempt to standardize a format for such metadata, so that it can become a target for more tools (note that these would *not* be necessary for packaging!) going forward. According to the author of the PEP, [`pipx`](https://pypi.org/project/pipx/) also has support for this feature implemented; but as far as I can tell, this refers to a development version not yet released.
- Speaking of which, the discussion for the PEP just pointed me at another tool that seems reasonably fit for purpose, and much more lightweight than the above script-runners: [`viv`](https://github.com/daylinmorgan/viv). The model here is that scripts can explicitly register their dependencies by importing the main Viv module and telling it to `.use` a third-party package (identified by a string name).
#2: Post edited
by
Karl Knechtel
·
2023-08-02T04:33:02Z (over 1 year ago)
add another option
- A compromise exists between automatically inferring package names (unreliable and potentially dangerous) and writing out an explicit separate `requirements.txt` file: script-running tools such as [`pip-run`](https://pypi.org/project/pip-run/) may offer the ability to parse requirements declared explicitly within the source file itself, and also allow specifying dependencies explicitly on the command line. Above and beyond managing dependencies, tools like this are designed to provide an isolated environment for the script (by automatically creating a virtual environment) - among other things, this means an error in the dependencies won't mess up your existing environment.
- When the script is your own code, then, it's easy to leave a note about dependencies that won't require *later remembering* that e.g. up-to-date versions of `PIL` need to be provided by `pip install pillow` instead. For others' code, at least there is a simpler way for others to communicate the *exact* requirements without distributing a separate file.
The proposed [PEP 722](https://pep-previews--3210.org.readthedocs.build/pep-0722/) (currently being heavily discussed [on the Python Discourse forum](https://discuss.python.org/t/_/29905)) is an attempt to standardize a format for such metadata, so that it can become a target for more tools (note that these would *not* be necessary for packaging!) going forward. According to the author of the PEP, [`pipx`](https://pypi.org/project/pipx/) also has support for this feature implemented; but as far as I can tell, this refers to a development version not yet released.
- A compromise exists between automatically inferring package names (unreliable and potentially dangerous) and writing out an explicit separate `requirements.txt` file: script-running tools such as [`pip-run`](https://pypi.org/project/pip-run/) may offer the ability to parse requirements declared explicitly within the source file itself, and also allow specifying dependencies explicitly on the command line. Above and beyond managing dependencies, tools like this are designed to provide an isolated environment for the script (by automatically creating a virtual environment) - among other things, this means an error in the dependencies won't mess up your existing environment.
- When the script is your own code, then, it's easy to leave a note about dependencies that won't require *later remembering* that e.g. up-to-date versions of `PIL` need to be provided by `pip install pillow` instead. For others' code, at least there is a simpler way for others to communicate the *exact* requirements without distributing a separate file.
- The proposed [PEP 722](https://pep-previews--3210.org.readthedocs.build/pep-0722/) (currently being heavily discussed [on the Python Discourse forum](https://discuss.python.org/t/_/29905)) is an attempt to standardize a format for such metadata, so that it can become a target for more tools (note that these would *not* be necessary for packaging!) going forward. According to the author of the PEP, [`pipx`](https://pypi.org/project/pipx/) also has support for this feature implemented; but as far as I can tell, this refers to a development version not yet released.
- Speaking of which, the discussion for the PEP just pointed me at another tool that seems reasonably fit for purpose, and much more lightweight than the above script-runners: [viv](https://github.com/daylinmorgan/viv). The model here is that scripts can explicitly register their dependencies by importing `viv` and telling it to `.use` a third-party package (identified by a string name).
#1: Initial revision
by
Karl Knechtel
·
2023-08-02T00:41:36Z (over 1 year ago)
A compromise exists between automatically inferring package names (unreliable and potentially dangerous) and writing out an explicit separate `requirements.txt` file: script-running tools such as [`pip-run`](https://pypi.org/project/pip-run/) may offer the ability to parse requirements declared explicitly within the source file itself, and also allow specifying dependencies explicitly on the command line. Above and beyond managing dependencies, tools like this are designed to provide an isolated environment for the script (by automatically creating a virtual environment) - among other things, this means an error in the dependencies won't mess up your existing environment. When the script is your own code, then, it's easy to leave a note about dependencies that won't require *later remembering* that e.g. up-to-date versions of `PIL` need to be provided by `pip install pillow` instead. For others' code, at least there is a simpler way for others to communicate the *exact* requirements without distributing a separate file. The proposed [PEP 722](https://pep-previews--3210.org.readthedocs.build/pep-0722/) (currently being heavily discussed [on the Python Discourse forum](https://discuss.python.org/t/_/29905)) is an attempt to standardize a format for such metadata, so that it can become a target for more tools (note that these would *not* be necessary for packaging!) going forward. According to the author of the PEP, [`pipx`](https://pypi.org/project/pipx/) also has support for this feature implemented; but as far as I can tell, this refers to a development version not yet released.