3 ms·

> automatic generation of AUTHORS and ChangeLog files based on git history I used to think this was a good idea. Then I found a huge loophole in it: if I copy-

> automatic generation of AUTHORS and ChangeLog files based on git history I used to think this was a good idea. Then I found a huge loophole in it: if I copy-paste code from another FLOSS project, then that code's author should still be listed, but won't have any commits. Also, peer-programming. > version management based on git tags setuptools-scm already does this for us. Finally, a big upside of setup.py, is that I can programatically generate information, whereas pbr's cfg file doesn't seem to allow that. flavors are listed as a big deal, but much like the article says, setuptools already has this, nothing new here.

shaded-enmity 9y ago
> Finally, a big upside of setup.py, is that I can programatically generate information, whereas pbr's cfg file doesn't seem to allow that. The problem with package manifests that are arbitrary scripts (Python, Ruby and probably others) is that you lose even basic introspectability into rudimentary parameters like name, version, dependencies unless your threat model allows for executing random code that people put into the setup.py. This can be mitigated by using complex static analysis carefully crafted for the specific task, but this isn't easy to implement and there is a non-insignificant amount of cases where the data cannot be legitimately decided. I'm just wondering how this is conceptually different from Pipfiles: https://github.com/pypa/pipfile https://github.com/pypa/pipfile (Previous discussion https://news.ycombinator.com/item?id=13011932 https://news.ycombinator.com/item?id=13011932)
- daenney 9y ago
  Pipfile isn't a replacement for setup.py, it's meant to replace requirements.txt / how you specify the dependencies of your project. As you've noted, setup.py can do a lot more than that.
- ubernostrum 9y ago
  Also, executable package scripts with arbitrary code are the reason why 'pip install rickroll' does exactly what it sounds like it'll do.
Daviey 9y ago
>> automatic generation of AUTHORS and ChangeLog files based on git history >I used to think this was a good idea. Then I found a huge loophole in it: if I copy-paste code from another FLOSS project, then that code's author should still be listed, but won't have any commits. If you think that the other person deserves all the credit for the change, set the author with: git commit --author="Guido van Rossum <guido@python.org>" If you deserve the responsibility/credit/blame for the commit, give credit to the other person in such a way pbr will pick it up, by adding to your commit message: Co-authored-by: Guido van Rossum <guido@python.org>

shaded-enmity 9y ago

> Finally, a big upside of setup.py, is that I can programatically generate information, whereas pbr's cfg file doesn't seem to allow that. The problem with package manifests that are arbitrary scripts (Python, Ruby and probably others) is that you lose even basic introspectability into rudimentary parameters like name, version, dependencies unless your threat model allows for executing random code that people put into the setup.py. This can be mitigated by using complex static analysis carefully crafted for the specific task, but this isn't easy to implement and there is a non-insignificant amount of cases where the data cannot be legitimately decided. I'm just wondering how this is conceptually different from Pipfiles: https://github.com/pypa/pipfile https://github.com/pypa/pipfile (Previous discussion https://news.ycombinator.com/item?id=13011932 https://news.ycombinator.com/item?id=13011932)

daenney 9y ago
Pipfile isn't a replacement for setup.py, it's meant to replace requirements.txt / how you specify the dependencies of your project. As you've noted, setup.py can do a lot more than that.
ubernostrum 9y ago
Also, executable package scripts with arbitrary code are the reason why 'pip install rickroll' does exactly what it sounds like it'll do.

Daviey 9y ago

>> automatic generation of AUTHORS and ChangeLog files based on git history >I used to think this was a good idea. Then I found a huge loophole in it: if I copy-paste code from another FLOSS project, then that code's author should still be listed, but won't have any commits. If you think that the other person deserves all the credit for the change, set the author with: git commit --author="Guido van Rossum <guido@python.org>" If you deserve the responsibility/credit/blame for the commit, give credit to the other person in such a way pbr will pick it up, by adding to your commit message: Co-authored-by: Guido van Rossum <guido@python.org>