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

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 setup.py 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 setup.py file using a command like pipenv generate setup.py or something similar. This command would take the metadata and package dependencies and output a setup.py. 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 setup.py 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 setup.py, 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 setup.py 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 setup.py.

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_PROGRAM
• NVM_CD_FLAGS
• ANDROID_HOME
• PYENV_ROOT
• TERM
• SHELL
• TMPDIR
• Apple_PubSub_Socket_Render
• TERM_PROGRAM_VERSION
• TERM_SESSION_ID
• PYENV_VERSION
• ZSH
• NVM_DIR
• USER
• SSH_AUTH_SOCK
• PYENV_DIR
• __CF_USER_TEXT_ENCODING
• PYENV_VIRTUALENV_INIT
• VIRTUAL_ENV
• PAGER
• PYENV_VIRTUAL_ENV
• LSCOLORS
• PATH
• PWD
• JAVA_HOME
• DEFAULT_USER
• LANG
• ITERM_PROFILE
• PYENV_HOOK_PATH
• _OLD_VIRTUAL_PS1
• XPC_FLAGS
• XPC_SERVICE_NAME
• PYENV_SHELL
• SHLVL
• HOME
• COLORFGBG
• GOROOT
• ITERM_SESSION_ID
• LESS
• LOGNAME
• LC_CTYPE
• NVM_BIN
• DISPLAY
• COLORTERM
• PYTHONDONTWRITEBYTECODE
• PIP_PYTHON_PATH

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

---

[uranusjr]

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!

[gsemet]

This is an old debate and there are no I’ve solution. Libraires need to define their dependencies in their install_require section of setup.py. 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 setup.py without requirements/Pipfile. Especially since they cannot pin the version because you want your lib to work on many configuration.