I had never heard of pipenv but recently ran into an issue. I updated my upstream (fork) of cfn-resource-provider but didn't know to rerun pipenv lock so I was troubleshooting an issue that was fixed in upstream but frozen (on a broken version) in my Pipfile.lock. It seems to me that you wouldn't, in general, want to do this in the repo because it would prevent your package from ever picking up upstream fixes of any sort. The first time you make test, it should be generated and provide stability from that point forward.
I had never heard of
pipenv
but recently ran into an issue. I updated my upstream (fork) ofcfn-resource-provider
but didn't know to rerunpipenv lock
so I was troubleshooting an issue that was fixed in upstream but frozen (on a broken version) in myPipfile.lock
. It seems to me that you wouldn't, in general, want to do this in the repo because it would prevent your package from ever picking up upstream fixes of any sort. The first time youmake test
, it should be generated and provide stability from that point forward.