Skip to main content

Pypackage looks to package python without writing a setup.py

Project description

Pypackage

View this on GitHub Pages

Build Status Coverage Status Version Download format Downloads this month Development Status License

Pypackage is a collection of python packaging applications including:

py-build
py-develop
py-install
py-setup
py-test

The main goal of Pypackage is to make python packaging easier and faster.

Wouldn’t it be nice if you could just write some python, run a command, and have a distributable package? Well now you can!

Features

  • automatic python modules and packages detection

  • automatic inclusion of non-python package data files, and their inclusion in and writing of the MANIFEST.in

  • support for three different testing frameworks (pytest, nose, and unittest) for use with setup.py test

  • automatic script detection (any executable file in ./bin or ./scripts)

  • automatic version, author, maintainer and email(s) detection (perfers __init__.py, __version__.py)

  • curses front-end to python classifiers selection

Example, “Hello World” application:

$ mkdir hello_world
$ cd hello_world
$ vim hello_world.py   # write your python here... :)
$ py-build -is

The py-build -is command will take you through an interactive py-build session and save the setup.py to disk after creating it, but will not run it.

You can also use the py-setup command at any time to print what Pypackage would use as a setup.py in the current directory’s context.

Metadata can be mixed in with site-wide defaults from $HOME/.pypackage if you want to fill in some common attributes for all your projects.

Pypackage also provides three different test runners to automatically find and run your tests with python setup.py test, you can use any of pytest, nose or unittest.

To be clear though: pypackage does not intend on replacing setuptools, pip, or really anything at all in the python packaging tool-chain, it only attempts to complement those utilities and make getting started with python packaging a little easier.

In my utopian perfect dream world, I’d see projects not having a setup.py under source control, instead only a static metadata file, then having the inverse relationship being true in the distribution version of the package.

Example, write Python and send it to PyPI

First, configure your ~/.pypirc file with a [pypi] section if you haven’t already. Now, assuming you lay out your project something like:

./your_project
./your_project/README.md
./your_project/pypackage.meta
./your_project/...
./your_project/your_project/__init__.py
./your_project/your_project/your_code.py
./your_project/your_project/...

With pypackage installed, from ./your_project run the following commands to send your project to PyPI for the first time:

$ py-build
$ py-build -s
$ python setup.py register
$ twine upload dist/* || pip install twine && twine upload dist/*

Every time after that, to update your package is a two step process:

$ py-build
$ twine upload dist/*

This will upload a binary wheel and source distribution to PyPI so you can share your work with the world.

The source distribution will include a setup.py and will not include the pypackage.meta if you use one. In this way, Pypackage does not create a build dependency on your distribution, but rather only on your source, or perhaps more specifically, your build chain and/or development environment. Unless you choose to develop off of the distributed source version, then carry on doing your thing. Just don’t submit any patches to the setup.py because it’s not a real thing in the source. As a project maintainer, you may even consider adding setup.py to the .gitignore of your pypackaged projects.

Further examples

If your OS can run a bash script, execute demo.sh in the top level of this repo to create a new pypackage venv and some simple example packages in an example directory. From there feel free to play around and experiment with pypackage features and applications.

Screenshots

The following screenshots were all taken with the detected_pkg package, which is created by the demo.sh script described in the further examples section above.

Curses top level classifiers selection screen:

top level classifiers

Curses development status screen with Beta selected:

development status classifiers

Interactive build process which used the above in it’s classifiers selection:

`py-build -si` interactive build session

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

pypackage-0.1.5.tar.gz (41.6 kB view hashes)

Uploaded Source

Built Distribution

pypackage-0.1.5-py2.py3-none-any.whl (35.2 kB view hashes)

Uploaded Python 2 Python 3

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page