dist creation commands

Issue #232 on hold
Ronny Pfannschmidt created an issue

in order to support creation/installation of wheels as well as custom distribton generators it seems sensible to add a global option for the sdist creation command

it should default to python setup.py sdist but allow people to override with something like python setup.py sdist bdist_wheel

in addition a global option is required to check if all requirements for the sdist creation are availiable

i propose to add the keys

dist_command for the command and dist_requires for the requirements needed to create the distribution (this would also allow to add requirements for recent setuptoolsand setup time dependencies)

whether the implementation creates a virtualenv to install those or tells the user to do so is up for implementation

in case of virtualenv creation we can also support specifying exact/desired tox versions there

Comments (9)

  1. Holger Krekel repo owner

    doesn't a package define with setup_requires what it needs? The main points about making the package creation configurable are IMO:

    • specifying an env where to run the build/packaging command
    • specifying the command to be executed
    • what if multiple artifacts are created?
  2. Ronny Pfannschmidt reporter

    setup_requires will run easy_install and create a mess, avoiding triggering that is desirable

    a env to create packages seems indeed the best solution i wonder if we can map artifact extensions to factors (after all the common use case is whl vs sdist)

  3. Holger Krekel repo owner

    not sure i follow. I currently don't consider having tox generate different packages and testing them. rather i'd put this into something connected to devpi.

  4. Rob Messick

    +1 on this. In our workflow, artifacts are not uploaded to devpi unless the tests pass. We need the source distributions to use .tar as the archive format since .zip doesn't preserve filemode.

  5. T

    +1. This seems also very helpful for packages that have setup.py files that only run in Python 3, while tox is commonly installed by linux distributions with Python 2. (rare I suppose, but not unthinkable) Running the sdist command in a virtualenv with the same python versions as the actual tests/allowing to specify the python interpreter for running sdist would solve/prevent this.

  6. T

    Yes in fact I just had to do the same - and when I saw tox simply runs an external command with "/usr/bin/python" at the start to do sdist I thought "hum, it would be neat if it was simply possible to tell it to run python3 instead, wouldn't it?".

  7. Log in to comment