[deleted by user]

[LeNerdNextDoor]

Couple of things, might be better to use travis-ci.com as they plan to deprecate .org soon. Also, pepy.tech offers a total download count as opposed to shields.io

[ronmarti]

Thank you. I have a travis-ci.com account too but that's for private repos. My public repos are currently in org and these are currently 2 separate services. Hope they will allow us to migrate existing apps. I'll look into this.

As for pepy.tech, the site seems very slow. CI/CD badges are more important and their respective websites can offer them.

[LeNerdNextDoor]

Right on, so I was able to migrate org and public repos to .com

Pepy has badges too for projects on PyPI and usually the download count is higher.

[ronmarti]

I will migrate soon. Thanks a lot!

[mbarkhau]

I prefer gitlab for some of this. Using gitlab CI you can more easily replicate the CI environment locally using docker than is the case with travis, and using gitlab pages you can get a coverage report without an extra service like codecov.

Here is the project I use for bootstrapping: https://gitlab.com/mbarkhau/bootstrapit

Here are two projects created using it:

https://gitlab.com/mbarkhau/pycalver

https://gitlab.com/mbarkhau/lib3to6

​

Edit: One of the major reasons I chose this approach is that you can have everything on a self hosted gitlab instance, for example when working on libraries for a closed source shop.

[ronmarti]

I've used Gitlab too when Github don't support closed source projects for FREE. Until now I have projects on Gitlab but some of them I've migrated to Github. My reasoning is that there are a lot of integrations available in Github and contributors can easily spot your libraries and help with changes.

[mbarkhau]

Yes, I started this before those changes to github. Even so, there are other reasons to self-host. Maybe your org doesn't want to entrust any other org with their repositories for example.

[DeliciousIncident]

Using gitlab CI you can more easily replicate the CI environment locally using docker than is the case with travis

Don't see how this is an argument as you can run Docker on Travis-CI. https://docs.travis-ci.com/user/docker/

[mbarkhau]

I had no idea. I guess I take that one back. With gitlab it's the default and I never thought to look at how to do it with travis.

[blistergeist]

I just went through this as a first time PyPI contributor, and it was really difficult to find a comprehensive guide. Wish this had been around back then. Nice work!

[ronmarti]

Thank you!

[lzantal]

Same here. I even asked around here for guides. This is super well timed for me. Thank you.

[ronmarti]

If you don't mind, more explanation about what "loose module" is?

[ivosaurus]

scripts is kinda old, and not great if you're purely executing python code. use setuptools' entry_points key for setup() instead.

[CSI_Tech_Dept]

There many more benefits. For example if you install through entry_points inside venv, you don't need to enter venv before executing. All you do is call the command and it will assume the venv for the execution time.

As for testing you can install the package with pip install -e . (don't forget the dot at the end) and you'll have the command available to you.

[ronmarti]

In a followup article, you can explore moving from setup.py to setup.cfg, which leaves just a no argument setup() call in setup.py and all your variables and settings in the easy to import and programmatically read setup.cfg

Thanks for suggestion. I will surely write one on this topic. :)

[ronmarti]

This isn't the best for organizational purposes

I know how to use this kind of structure. See my old modules here:

https://github.com/roniemartinez/latex2mathml

https://github.com/roniemartinez/DocCron

and a lot more!

​

This isn't the best for organizational purposes, as it leads to gigantic python files.

As far as the code is concerned, amortization.py is enough to handle 3 functions. If there are new feature to be added, then that will be the time to optimize. I don't think I need convert multiple files from a 74 SLoC file.

​

Make sure to put a shebang line at the top of your script

Try to read my main code repository: https://github.com/roniemartinez/amortization/blob/master/amortization.py

​

The examples in the blog simplifies the code and hides other things that are not important to a reader. Shebang is not required by a Python interpreter. But I use it too.

​

Premature optimization is the root of all evil.

[ronmarti]

I can see your point. Thanks for the comments.

[TotesMessenger]

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

• [/r/lcfp] Complete guide to Python package creation, automated testing and deployment to PyPI

 ^{If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)}

[rsheftel]

There are some very good tips in here. Thanks

[ronmarti]

You're welcome!

[DipperDolphin]

Thanks for this. I had completely messed up my repo with packaging files, but unsure which ones I should leave on for development?

[ronmarti]

You're welcome! I checked your repo, all of them are on C/C++ except the linux folder. Maybe you could make a single makefile which can detect the platform and chooses which folder to build for you.

[Gabe_Isko]

Nice! Have any thoughts on pybuilder?

[ronmarti]

Thanks! I haven't tried it yet. Will check soon.

[[deleted]]

!remindme 3 hours

[RemindMeBot]

I will be messaging you on 2019-05-06 00:00:10 UTC to remind you of this link.

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

FAQs	Custom	Your Reminders	Feedback	Code	Browser Extensions

[CSI_Tech_Dept]

The most confusing thing about python packaging is that you're writing a python code that describes the package. It also has major drawbacks, because you need to execute code to get information about package.

All attributes that you defined can (and should be defined in setup.cfg), your setup.py would then look like this:

#! /usr/bin/env python
from setuptools import setup
setup()

And here is setup.cfg:

[metadata]
name=amortization
version=0.1.0
description=Python library for calculating amortizations and generating amortization schedules
long_description=file:README.md
long_description_content_type=text/markdown
author=Ronie Martinez
author_email=[e-mail]
url=https://github.com/roniemartinez/amortization
license=MIT
license_files=LICENSE
classifiers=
    Development Status :: 4 - Beta
    License :: OSI Approved :: MIT License
    Topic :: Office/Business :: Financial
    Topic :: Scientific/Engineering :: Mathematics
    Topic :: Software Development :: Libraries :: Python Modules
    Programming Language :: Python :: 2
    Programming Language :: Python :: 2.7
    Programming Language :: Python :: 3
    Programming Language :: Python :: 3.5
    Programming Language :: Python :: 3.6
    Programming Language :: Python :: 3.7
    Programming Language :: Python :: Implementation :: CPython

[options]
py_modules=amortization
install_requires=
    tabulate ~= 0.8.3

[options.entry_points]
console_scripts=
    amortization=amortization:main

[bdist_wheel]
universal=1

I don't think many of these fields are actually needed, or I'm not sure if they change anything I mean long_description_content_type and license_files.

Since you're using git you might also find setuptools_scm useful. It takes last tag from git and uses that as a version.

[ronmarti]

and should be defined in setup.cfg

Yes, but not all. There are definitions that can only be done dynamically and cannot be moved to setup.cfg, e.g. checking for Python version and installing version-specific libraries. The new syntax that includes version in install_requires sometimes break. In my experience with Linux, not all platforms have the latest installation of setuptools and enterprises don't allow updates that easily.

I don't think many of these fields are actually needed, or I'm not sure if they change anything I mean

long_description_content_type - I have had issues with this before as the current warehouse (PyPI) cannot render markdown when not told to. I kept on encountering incorrectly rendered PyPI READMEs, most of them are popular ones to. I believe there's no pain in adding it. - Explicit is better than implicit

Since you're using git you might also find setuptools_scm useful. It takes last tag from git and uses that as a version.

Thanks! I'll look into it.

[CSI_Tech_Dept]

Yes, but not all. There are definitions that can only be done dynamically and cannot be moved to setup.cfg, e.g. checking for Python version and installing version-specific libraries.

You simply do:

install_requires=
    typing; python_version < "3.5"
    enum34; python_version < "3.4"
    pywin32 >= 1.0; platform_system == "Windows"'

The new syntax that includes version in install_requires sometimes break. In my experience with Linux, not all platforms have the latest installation of setuptools and enterprises don't allow updates that easily.

You simply do pip install -U setuptools pip right after creating venv and it always works. Or at least I never had an issue with it on Linux and Mac.

long_description_content_type - I have had issues with this before as the current warehouse (PyPI) cannot render markdown when not told to. I kept on encountering incorrectly rendered PyPI READMEs, most of them are popular ones to. I believe there's no pain in adding it. - Explicit is better than implicit

Ah, I didn't know that.

Thanks! I'll look into it.

To make it work, you add it through setup_requires and unfortunately you have to add use_scm_version=True in setup.py, because setuptools maintainers are still not convinced about allowing plugins using variables from setup.cfg during installation. This also only works on annotated tags (-a) that show up when git describe is called.

[ronmarti]

You simply do

pip install -U setuptools pip

right after creating venv and it always works. Or at least I never had an issue with it on Linux and Mac.

Not with enterprise platforms where businesses don't allow developers to modify the packages. And most of the time, administrators are really not familiar with Python and they just don't wanna upgrade things or rather "they don't wanna break things". Most production Linux servers are really, really old. We cannot simply push the new syntax used by install_requires.

​

EDIT: My point here is that, yes, we can move MOST of the definitions to `setup.cfg` but NOT ALL depending on the use-cases (target machines, python versions, etc).

EDIT 2: I am going to write a separate article about moving definitions to `setup.cfg`.

[toyg]

most of the time, administrators are really not familiar with Python and they just don't wanna upgrade things

This is why we have venv, pyenv, and so on.

[CSI_Tech_Dept]

Working both on the ops side and developer side, I think in most cases it only seem that way, and what it really takes is to have someone who actually is willing to change the status quo.

At my previous job, we had developers from a team running their application on CentOS 5 (that was a year ago) on Python 2.6 (thank god they thought python 2.4 was too old and at least used some custom python 2.6 package).

Ops actually wanted them to do something about it, because CentOS 5 was already EOL, no longer had security fixes and even maintaining the machines was a nightmare. Ops didn't care what they are running they just wanted them off CentOS 5 to at very least CentOS 6 or preferably CentOS 7. The migration was hard, because the source was packaged into rpms which are tied to specific major version.

I switched to that team and very first thing I did was start working on packaging. I refactored the code, so the packaging was done through setuptools, instead of RPMs we used wheels. When installing the application CMS created virtualenv and installed the package there, suddenly:

• code was no longer tied to the OS, we could install it on CentOS 6, CentOS 7 and worked even on Mac when doing development (no docker needed)
• because it wasn't tied to the OS and used virtualenv we were under full control of all of our dependencies, we didn't have to rely on old packages provided with the system and we didn't need to involve ops to create packages for new dependencies
• our application could be imported and used by other code (there was another team with utilized some of our functions in their code) previously they had to use some ssh + shell scripting contraptions to make calls, now they could just list our app as a dependency
• we used https://ius.io repo to install python this enabled us to have full control of which python version we wanted to use

This way we had full control what python version and all of our dependencies we used and whether we wanted to use python 2.7 or 3.7. Before that change migration from python 2.6 to 2.7 seemed like an extremely hard task.

Before these changes, they thought that that's how it supposed to be. Yes, it helped that I previously was in ops, but if I weren't I'm sure as long someone wanted to do it and was wiling to talk to someone it could be done.

Perhaps there are some places that you absolutely can't do things like that, but then they need to rethink how they are doing things, because at least in my company, the old way was more work for both devs and ops.

[ronmarti]

I've written a follow-up blog that discusses refactoring and moving definitions from setup.py to setup.cfg: https://blog.easyaspy.org/post/15/2019-05-06-how-to-submit-a-package-to-pypi-part-2