Our great sponsors
-
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.
-
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
Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.
-
Check out pip-tools [1] which does exactly that, albeit in a slightly more polished way.
-
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.
-
> 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.
-
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.