A not so unfortunate sharp edge in Pipenv

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • Pipenv

    Python Development Workflow for Humans.

  • There is an issue from 2019 on the pipenv tracker for this issue: https://github.com/pypa/pipenv/issues/3893

    According to the last comment there it should be fixed:

    > I don't think this should be an issue in the current 2022.4.8 release because of the requirement to use index restricted packages for locking. Please advise if you think this is still a concern and we can revisit it.

    But apparently it is still an issue (assuming the author did use a recent enough pipenv version)

    From the article:

    > Overall this is pipenv working exactly as it should.

    I don't agree, IMO pipenv should just install from the source package and ignore the newer wheel, maybe showing a warning about the new wheel.

    I prefer to use https://python-poetry.org/ instead of pipenv, since it has less issues in my experience. But I wonder how it would behave in this situation.

  • Poetry

    Python packaging and dependency management made easy

  • There is an issue from 2019 on the pipenv tracker for this issue: https://github.com/pypa/pipenv/issues/3893

    According to the last comment there it should be fixed:

    > I don't think this should be an issue in the current 2022.4.8 release because of the requirement to use index restricted packages for locking. Please advise if you think this is still a concern and we can revisit it.

    But apparently it is still an issue (assuming the author did use a recent enough pipenv version)

    From the article:

    > Overall this is pipenv working exactly as it should.

    I don't agree, IMO pipenv should just install from the source package and ignore the newer wheel, maybe showing a warning about the new wheel.

    I prefer to use https://python-poetry.org/ instead of pipenv, since it has less issues in my experience. But I wonder how it would behave in this situation.

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • pip-tools

    A set of tools to keep your pinned Python dependencies fresh.

  • Check out pip-tools [1] which does exactly that, albeit in a slightly more polished way.

    [1]: https://github.com/jazzband/pip-tools

  • pvp

    PvP - The Ultimate Python Virtualenv and Package Manager

  • I use a small shell script I wrote in jest a year ago (https://github.com/senko/pvp), it boils down to virtualenv and pip, and it basically solves all Python package management issues for me.

    I was burned by pipenv before (naively trying to use it because a certain prominent member of Python community hyped it up, and I hadn't known he'd gone off the rails). I can find no redeeming qualities to it whatsoever, and it scarred me enough that I don't want to touch other newer tools (poetry, pdm, whatever) with a 10ft pole.

    I find solace in pip and virtualenv just working and not trying to be too clever.

    I pin all my immediate reqs, and if there's a conflict with indirect deps (which happened maybe once or twice), I figure out the version I need and pin that manually.

    For packaging I rely on specialized tools that do just that (build, twine), and don't need one-with-everything spaceship of a tool.

    I also develop in Node and have suffered much more grief by npm. I lost count of the number of times where I had to rm-rf node modules and npm cache, rerun and hope for the best.

  • npm

  • > which can be overriden with env setting

    Support for this is not great. Lots of packages still don't support this properly. My experience matches the 2015 comment https://github.com/npm/npm/issues/775#issuecomment-71294085

    > Not sure why "symlinks" would be involved.

    If you make your node_modules a symlink, multiple packages will fail. Even if you're not interested in doing that, others are.

    > What NPM does is leaps and bounds ahead

    Unless you change your node / gyp version. It doesn't really have a concept of runtime version. You can restrict it, but not have two concurrent versions if they conflict.

  • sops

    Simple and flexible tool for managing secrets

  • I recommend against with using secrets managers as opposed to config files for storing configuration. Ideally, your configuration is versioned and code-reviewed. Config files are optimal. Even secrets used by your deployment should be stored in configuration - encrypted, of course. The benefit of versioned configuration files, secrets included, cannot be overstated.

    You can encrypt sensitive configuration fields with tools like `mozilla/sops` [1], which will reach out to your KMS or secrets manager of choice to encrypt/decrypt sensitive fields on the fly.

    This way, you are minimizing the splitting of state across secrets managers and your code. Your configuration is stored at code, code reviewed, and versioned, which has devops and security benefits of its own.

    [1]: https://github.com/mozilla/sops

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts