Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Project Metadata in Pipfile (name, version, license, ...)

See original GitHub issue

NOTE: I am including the request here and not sending it to the wiki because it current says that the wiki is not up.

Is your feature request related to a problem? Please describe.

First of all, I really like how Pipenv simulates much of the functionality of npm / yarn and package.json files that are used in Node.js development. It is really clean, simple, and consistent. One thing that I find frustrating with my current Pipenv setup for developing libraries is having to manage a separate file for publishing to PyPi.

Describe the solution you’d like

As I mentioned above, I think that (like in the Node.js toolchain), metadata about the project should be stored in the Pipfile and initialized by pipenv. Using a command like pipenv init, users can input optional values for fields like name, version, license, description, and so on. They can also use pipenv init -y to fill in default values or something similar.

In addition, with this information, it would be possible to generate a file using a command like pipenv generate or something similar. This command would take the metadata and package dependencies and output a This command can be integrated in a CI toolchain if desired.

Describe alternatives you’ve considered

Of course, the current alternative is to manage a which contains the metadata about the project. This is the current base method, which in some ways makes more sense, but is also harder to manage.

Benefits: First of all, a lot of the metadata that I am proposing is only necessary when developing libraries and not applications. So if someone uses pipenv in their application, they may not find this feature useful. Of course, they can choose not to include that information in the Pipfile or skip the fields in pipenv init. Also, application developers have no need for a, so the feature is not necessary for them.

Drawbacks: For package developers, this setup adds a lot of extra complexity. They have to manually create a file with the metadata and a list of package dependencies. So as they add packages in pipenv, they would have to manually add them in the

Additional context

In order to include the metadata within the Pipfile, it must be placed in a current section or a new section called info or something. Therefore, the Pipfile specification would also have to changed, or pipenv would not follow the standard. This would definitely be a problem, but I am not sure how important it is to follow the Pipfile standard as it is currently under active design. It also seems like pipenv currently doesn’t exactly follow the standard; I don’t think Pipfiles should include the ‘scripts’ section even though pipenv currently supports it.

I would love to help develop this feature and make a PR, but I would like other’s opinions before continuing.

$ pipenv --support

Pipenv version: '2018.7.1'

Pipenv location: '/Users/SrinuL/.pyenv/versions/3.7.0/envs/pipenv/lib/python3.7/site-packages/pipenv'

Python location: '/Users/SrinuL/.pyenv/versions/3.7.0/envs/pipenv/bin/python'

Other Python installations in PATH:

  • 2.6: /usr/bin/python2.6

  • 2.6: /usr/bin/python2.6

  • 2.7: /usr/bin/python2.7

  • 2.7: /Users/SrinuL/.pyenv/shims/python2.7

  • 2.7: /usr/bin/python2.7

  • 3.6: /Users/SrinuL/.pyenv/shims/python3.6

  • 3.7: /Users/SrinuL/.pyenv/versions/pipenv/bin/python3

  • 3.7: /Users/SrinuL/.pyenv/shims/python3.7

  • 3.7.0: /Users/SrinuL/.pyenv/versions/pipenv/bin/python

  • 3.7.0: /Users/SrinuL/.pyenv/shims/python

  • 2.7.10: /usr/bin/python

  • None: /Users/SrinuL/.pyenv/shims/python2

  • 3.7.0: /Users/SrinuL/.pyenv/versions/pipenv/bin/python3

  • 3.7.0: /Users/SrinuL/.pyenv/shims/python3

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '3.7.0',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '16.7.0',
 'platform_system': 'Darwin',
 'platform_version': 'Darwin Kernel Version 16.7.0: Thu Jan 11 22:59:40 PST '
                     '2018; root:xnu-3789.73.8~1/RELEASE_X86_64',
 'python_full_version': '3.7.0',
 'python_version': '3.7',
 'sys_platform': 'darwin'}

System environment variables:

  • TERM
  • Apple_PubSub_Socket_Render
  • ZSH
  • USER
  • PATH
  • PWD
  • LANG
  • HOME
  • LESS

Pipenv–specific environment variables:

Debug–specific environment variables:

  • PATH: /Users/SrinuL/.pyenv/versions/pipenv/bin:/usr/local/Cellar/pyenv/1.2.5/libexec:/Users/SrinuL/.nvm/versions/node/v8.1.3/bin:/usr/local/Cellar/pyenv-virtualenv/1.1.3/shims:/Users/SrinuL/.pyenv/shims:/Users/SrinuL/.pyenv/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/TeX/texbin:/Users/SrinuL/Library/Android/sdk/tools:/Users/SrinuL/Library/Android/sdk/platform-tools:/usr/local/opt/go/libexec/bin
  • SHELL: /bin/zsh
  • LANG: en_US.UTF-8
  • PWD: /Users/SrinuL/testing
  • VIRTUAL_ENV: /Users/SrinuL/.pyenv/versions/3.7.0/envs/pipenv

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:6 (5 by maintainers)

github_iconTop GitHub Comments

uranusjrcommented, Jul 22, 2018

Pipfile is designed specifically to avoid including these information. Not every application is a package, and Pipenv is designed to handle the There are tools that can handle this perfectly, such as flit, pbr. You can add your package dependencies there (instead of Pipfile), and run pipenv install -e . against your package to make Pipenv pick up the dependencies listed there.

Another point to consider is that, not every application has the same dependencies when used as a standalone application and an installable library. Pipenv draws a very clear line here, and does not assume that package requirements are the same as abstract application requirements. See various discussions on this topic, #209 #1161 #1263 etc.

Pipfile is actually an easy target to interpolate against. Pipenv does not care what sections you put inside it (it only reads what it needs, and keep the rest intact). Also, most of Pipenv’s interaction with Pipfile is provided by a standalone library (sarugaku/requirementslib). You should be able to build a standalone library to provide the packaging features you need, without adding anything to Pipenv.

To conclude, Pipenv does not actively provide packaging functionalities, and leaves this to other tools. We do strongly encourage people to build tools to interact with Pipfile, and to work alongside with Pipenv. We’d be more than happy to introduce the tool to others as well, if you build it 🤞

I’m closing this since the proposed functionality is out of the scope of this project, but please do feel free to ask if you need any help on the project (I for one would be interested in contributing, shoot me with an email and we can discuss), or when you want to inform us about any progress you’ve made. Good luck!

gsemetcommented, Jul 23, 2018

This is an old debate and there are no I’ve solution. Libraires need to define their dependencies in their install_require section of Application may skip this and store their dependencies in requirements.txt/Pipfile. Pinning version is always tricky, so for app you may want to use pip-compile or pipenv.

In order to keep a single source of truth for libraries, in a requirement.txt/Pipfile (no lock file, because you don’t want to pin dep for libs), you need an extra layer of abstraction. I choose PBR (inject requirements.txt in install_require) and pipenv-to-requirement (generate requirement.txt from Pipfile) to still maintain a Pipfile in a library. But that’s a personal choice and most lib developers simply maintain a without requirements/Pipfile. Especially since they cannot pin the version because you want your lib to work on many configuration.

Read more comments on GitHub >

github_iconTop Results From Across the Web

pip-licenses - PyPI
Dump the software license list of Python packages installed with pip.
Read more >
pipenv Documentation - Read the Docs
Automatically install required Python version when pyenv is available. • Automatically finds your project home, recursively, by looking for a Pipfile.
Read more >
pipenv Documentation
Pipenv automatically maps projects to their specific virtualenvs. • The virtualenv is stored globally with the name of the project's root ...
Read more >
Packaging in Python: Tools and Formats | by Martin Thoma
After reading this article, you will understand what the following tools are and which problems they solve: pip, pyenv, venv, virtualenv, pipx, ...
Read more >
pyproject.toml - Martin Thoma
Also, other kinds of meta-data and the install requirements can be ... [project] name = "infer_pyproject" version = "0.1.0" description ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found