Zero all the things time.
Sick of needing 40 files in a python repo to release some code into the world? Me too. How do we fix that? In the spirit of the zero all the things movement... this is an exploration of that question.
Say we have our one file "leftpad.py" filled with our high tech left pad implementation. How to share that with people?
leftpad.py
"""Left pad takes a string, and pads it to the left.
With such advanced technology, after much research we bla
blabl blabla lorem ipsum bla bla. More nonsense which describes
more stuff in full.
"""
def leftpad(s, width, fillchar):
"""Return the string right justified in a string of length width. Padding is done using the specified fillchar (default is an ASCII space). The original string is returned if width is less than or equal to len(s).
"""
return s.rjust(width, fillchar)
We git commit -m "Added advanced left pad functionality.", and push it up to our repo.
We need this metadata at a minimum for a python package:
name - this is the name of our file or folder
description - the first line in our file.
long_description - the rest of the doc string
author - git gives us the author
author_email - git also gives us the author_email
version - we store this as git tags, but we can just increment this number from 0.0.1 for every git commit.
url - git again stores where we remotely push to.
This can generate all the boilerplate code that the python packaging world decides we needs and publishes to the cheeseshop.
What does our repo contain apart from our code? Nothing. Zero.
(You have finished part zero now, continue to part one?)
Sick of needing 40 files in a python repo to release some code into the world? Me too. How do we fix that? In the spirit of the zero all the things movement... this is an exploration of that question.
Say we have our one file "leftpad.py" filled with our high tech left pad implementation. How to share that with people?
leftpad.py
"""Left pad takes a string, and pads it to the left.
With such advanced technology, after much research we bla
blabl blabla lorem ipsum bla bla. More nonsense which describes
more stuff in full.
"""
def leftpad(s, width, fillchar):
"""Return the string right justified in a string of length width. Padding is done using the specified fillchar (default is an ASCII space). The original string is returned if width is less than or equal to len(s).
"""
return s.rjust(width, fillchar)
We git commit -m "Added advanced left pad functionality.", and push it up to our repo.
What metadata do we need?
We need this metadata at a minimum for a python package:
name="leftpad"But didn't we already enter that data somewhere? Yes we did!
description = "Left pad takes a string, and pads it to the left."
long_description = "With such advanced technology, after much research we bla blabl blabla lorem ipsum bla bla. More nonsense which describes
more stuff in full."
author="My Name Is"
author_email="myemail@example.com"
version="0.0.1"
url="https://github.com/mynameis/leftpad"
name - this is the name of our file or folder
description - the first line in our file.
long_description - the rest of the doc string
author - git gives us the author
author_email - git also gives us the author_email
version - we store this as git tags, but we can just increment this number from 0.0.1 for every git commit.
url - git again stores where we remotely push to.
How to release it?
packagezero release
This can generate all the boilerplate code that the python packaging world decides we needs and publishes to the cheeseshop.
What does our repo contain apart from our code? Nothing. Zero.
(You have finished part zero now, continue to part one?)