Please upload package to PyPI

[drrlvn]

Installing from pypi can be simpler and more user friendly than cloning and running some scripts.

[kuba]

That's definitely on my TODO list, I just didn't do enough release engineering yet. Sorry for the delay, I'll try to fix it ASAP!

[skorokithakis]

+1 on this, the current installation system is a bit unwieldy.

[asfaltboy]

It actually uploads as is (at least on my local devpi and pypitest). I'll add a tiny bit of meta-data to see if @kuba likes it.

Example: https://testpypi.python.org/pypi/simp_le . let me know if a PR is welcome and I'll send it.

[La0]

I've created a simple Ansible role to install simp_le on Debian/Ubuntu systems.
It installs all dependencies needed (system & python) and uses a virtualenv.

[kuba]

That's awesome, @La0. I've added a link to https://github.com/kuba/simp_le/wiki/Links.

[skorokithakis]

+1 on merging #25 and uploading, it looks great.

[kuba]

#25 brings us closer, but we're not yet there - hold your breath

[skorokithakis]

What's left to do?

[kuba]

I would like to write a release script such as https://github.com/letsencrypt/letsencrypt/blob/master/tools/dev-release.sh and think more carefully about the release process, including versioning scheme, changelogs etc. I'll do my best to finish this up within next 24 hours.

[asfaltboy]

@kuba here are my six cents (coz it's 3 things, so 2 cents * 3 = 6 cents get it)?:

1. letsencrypt's dev-release.sh is a bit of overkill; I'd apply project philosophy and keep it simp_le:

   • check if version differs than last tagged/released
   • create git tag and push to remote
   • upload to pypi

2. For versioning I'd suggest to follow (at least) the accepted identifier guidelines so that the package is pip-friendly (regardless of actual scheme used); here are some examples.

3. Changelog - I like how my favorite sublime git package implements an autogenerate changelog command.

   If you already use SublimeText, you can just use it; but in a nutshell, it does the following:

   • select a git ref(can be the last tag as in 1)
   • fetch a log of all commits since from ref up to head
   • split each commit message (by \x00) to extract contributors
   • further split commit message (by :) to group by change type

   This requires the commit message subject (1st row) to follow a particular pre-defined format.
   Alternatively, if you prefer to base changelog on github issues, you could run this kind of changelog generator.

[skorokithakis]

+1 on that suggestion as more Pythonic.

[hadim]

+1

[asfaltboy]

@kuba Any chance to have first version on pypi yet? We can even help with setting version / make changelog manually?

[kuba]

Actually, why do you need it to be on PyPI, @asfaltboy? Do you realize you can just pip install git+https://github.com/kuba/simp_le?

[asfaltboy]

True that, actually use our own devpi mirror, but I just like freezing things

[skorokithakis]

That will get the latest head, which may or may not work. What's the argument against this being on PyPI? It's the standard method of distribution.

[kuba]

I make absolute sure that master always works. If it doesn't then you can pip install git+https://github.com/kuba/simp_le@known_working_commit_id (which pretty much is very similar to what would happen if there was a broken release, but the response time would probably be much lower, because it would not require preparing a patched release, but just a single commit instead).

There are no arguments against being on PyPI other than my lack of time to commit to release cycle at this stage. Freezing does require some thinking, because it will impact the future of the project.

If there is any strong argument to have PyPI sooner, I will definitely consider it when prioritizing issues, but for now I don't see any and there are more itching issues. Everything will come at the right time... Be patient :)

[skorokithakis]

The main draw is that, since you already make sure master always works, you can just bump the version every commit and do ./setup.py sdist upload and PyPI would get the new version. It's pretty much as simple as that, and being able to easily pin to minor versions is very useful.

[peikk0]

Tagging a version would allow proper packaging in Linux distros, a git hash is not a proper version for a package.

[trunneml]

@kuba pip install with an git repository sometimes creates a big mess. May be creating a tag and a wheel file and uploading to github as a release artifact would be better idea? This way distros can create easily a package by using the wheel file. Also pip supports wheel files.

[asfaltboy]

Been using our private mirror pypi server for most of our simp_le deployment and thought I'd share my experience.

Firstly, binary distributions (like wheel) are immensely important, since production machines are often sterilized from compilers and the required develop libraries.

We've been maintaining wheels for all simp_le requirements for our target machines for this reason. And while it's been more or less smooth, some packages (e.g cffi) are required to be at least version X (>=X) and often updated, which requires recompilation.

An "ultimate" solution would be to distribuite the requirements together with simp_le, for example using pex.

I actually wrote a small proof of concept cli tool wrapping around simp_le and bundling requirements. I'll see if we can release it

[kuba]

Pavel, would you be ready to release it?

[asfaltboy]

Yes Jakub, I am able to publicize it, but I have to cleanup/generalize it slightly, so it would happen in the upcoming weekend only.

[asfaltboy]

Here is the package I mentioned: https://github.com/asfaltboy/make_ssl

[Siecje]

For versioning there is setuptools_scm which will use the latest tag and commits if they are after the latest tag.