Enable building Python packages for PyPI distribution #103

dralley · 2018-07-30T03:43:41Z

This will allow Python bindings and executables for createrepo_c to be distributed cross-distribution via PyPI.

To create a source distribution (requires the installer to have build dependencies installed, but not the builder), use python3 setup.py sdist.

To create a binary distribution (pre-compiled, does not require the installer to have build deps, caveat [0]), use python3 setup.py bdist_wheel. Note: you do need to have scikit-build package installed to build the package.

To install the package, use pip install dist/createrepo_c-*.tar.gz if it's an sdist package or pip install dist/createrepo_c-*.whl if it's a bdist. If it is an sdist package, the installer also needs to have the scikit-build package installed. New versions of pip >= 10.0 should handle this for you due to the pyproject.toml file, but pip < 10.0 will not.

Once uploaded to PyPI the package can be installed with pip install createrepo-c

Cmake build system changes

Added a toggle ENABLE_BASHCOMP, default ON, so that installing bash completions can be disabled if necessary.
Added a toggle CREATEREPO_C_INSTALL_DEVELOPMENT, default ON, so that installing header files and pkginfo can be disabled if necessary.
Added a toggle CREATEREPO_C_INSTALL_MANPAGES, default ON, so that installing manual pages can be disabled if necessary.
Added a toggle BUILD_LIBCREATEREPO_C_SHARED, default ON, so that libcreaterepo_c can be built statically if needed, e.g. built directly into the python extension library.
Added OPENSSL_INCLUDE_DIR variable to enable building against local/custom OpenSSL libraries.

Since these are general changes, if you would like me to split these changes out into separate Pull Requests, I can do so. However, they are prerequisites for this PR.

Python specific changes

Added a setup.py, requirements-dev.txt and pyproject.toml
Updated gitignore
CMake will take different paths if SKBUILD is set. SKBUILD is set by in the context of building a Python package by "scikit-build", which acts as a bridge between CMake and the Python packaging infrastructure.

[0] Binary distributions are not generally portable across different systems - a bdist created on Fedora 28 probably will not work on Ubuntu 16.04. However, there is a specific environment provided by Python Packaging Authority called manylinux, from which you can produce widely portable bdists. The current "manylinux1" environment is based on CentOS 5, which uses a GLib version too old to build createrepo_c. A new environment is in the works based on CentOS 6, but it is not officially ready yet. Thus, for the time being (but hopefully not for very long), it won't be possible to create a widely portable bdist package of createrepo_c.

dralley · 2018-07-30T04:02:40Z

I'd like to give enormous thanks to @jcfr for his help with this PR.

ignatenkobrain · 2018-07-30T05:28:10Z

setup.py

+    package_dir={
+        'createrepo_c': 'src/python'
+    },
+    cmake_args=['-DPYTHON_DESIRED:STRING=3', '-DBUILD_LIBCREATEREPO_C_SHARED:BOOL=OFF'],


you should pass sys.executable.

addressed in dralley@ee6df5f

ignatenkobrain · 2018-07-30T05:28:30Z

setup.py

+        'Topic :: System :: Systems Administration',
+        'Programming Language :: Python :: 3',
+    ),
+    python_requires=">=3.5",


not necessarily

Fixed in dralley@ee6df5f

jcfr · 2018-07-30T05:29:51Z

Follow-up to this PR can be found here: dralley#2

dralley · 2018-07-30T11:54:42Z

Follow-up merged

dralley · 2018-07-30T12:56:28Z

CMakeLists.txt

-    INSTALL(FILES createrepo_c.bash DESTINATION "/etc/bash_completion.d")
-    message("Bash completion directory: /etc/bash_completion.d")
-endif (BASHCOMP_FOUND)
+OPTION(ENABLE_BASHCOMP "Install Bash autocompletions?" ON)


Since we're being verbose for the other options, should this be named CREATEREPO_C_INSTALL_BASHCOMP to be more consistent?

Yes. Ideally, option specific to the project should be prefixed by the project name.

But this could be done in a different PR along with some other stylistic changes

dralley · 2018-07-30T20:28:21Z

src/python/__init__.py

+
+# Support running tests from the source tree
+if not os.path.exists(DATA):
+    from skbuild.constants import CMAKE_INSTALL_DIR as SKBUILD_CMAKE_INSTALL_DIR


Most users won't be installing an sdist via PyPI, they'll be using the normal RPM ~~or a bdist~~ - which means they won't have scikit-build available and will hit an ImportError. So I don't think this will work, unfortunately.

Putting that aside, something we've done has broken running tests using the normal build process documented in the README. I get

ERROR: Failure: ImportError (cannot import name _createrepo_c) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/loader.py", line 418, in loadTestsFromName addr.filename, addr.module) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 47, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python2.7/site-packages/nose/importer.py", line 94, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/home/vagrant/devel/createrepo_c/tests/python/tests/test_xml_parser.py", line 6, in <module> import createrepo_c as cr File "/home/vagrant/devel/createrepo_c/build/src/python/createrepo_c/__init__.py", line 8, in <module> from . import _createrepo_c ImportError: cannot import name _createrepo_c

From running ``` PYTHONPATH=readlink -f ./build/src/python/ nosetests -s tests/python/tests/````

despite that the path does have _createrepo_c.so on it.

[vagrant@pulp3 createrepo_c]$ ls build/src/python/createrepo_c/ _createrepo_c.so __init__.py __init__.pyc

Looking into what might be causing this currently. Tests work fine with the Python packages.

We can't rely on this - most users won't be installing via PyPI

This was only to support the case of local installation where the developer would create an editable install using python install -e . or python setup.py develop

running tests using the normal build process documented in the README has been broken by a change somewhere

More details in this post: https://groups.google.com/d/msg/scikit-build/XYfZFT2iFJM/lFEaEnm3CQAJ

@jcfr

This was only to support the case of local installation where the developer would create an editable install using python install -e . or python setup.py develop

I get that part, and I see where you're coming from :)

What I was getting at is that, in a normal, vanilla cmake build, e.g. simply running cmake ..; make etc. instead of python setup.py bdist_wheel, the code block isn't really valid, because Python packaging and scikit really aren't/shouldn't be involved in that scenario, and scikit might not even be installed on the machine, which would lead to an ImportError (which I experienced in testing that process).

I'm pretty sure it's only a problem if you're using Python bindings from a vanilla cmake build (surprisingly, the RPMs don't ship the bindings, apparently), but I don't want to break something that currently works unless a maintainer is ok with it. Also, it might become a problem if the RPMs did start including the bindings.

I think a solution might be to turn __init__.py into a template and inject the bin path directly from Cmake.

To summarize, there are two issues preventing editable from working.

By editable install, I mean the ability to run pip install -e . and then import createrepo_c

(1) python source should be moved from src/python/* to src/python/createrepo_c/*

(2) resolving the location of the compiled module should be fixed by either having a fallback to skbuild.constants or by hardcoding the expected location

@dralley The python bindings are shipped in Fedora, EPEL, Mageia, and openSUSE. Only SUSE Linux Enterprise currently does not ship them.

@Conan-Kudo Ah, I hadn't noticed it was built as a separate RPM package (python3-createrepo_c). Thanks.

(edit: new commit)

@jcfr I've moved src/python/__init__.py to src/python/createrepo_c/__init__.py, so I think everything is fine now on that front. My editable installation worked.

re: 2, Here is a possible solution (incomplete commit, going to lunch)

b8927ed

I think this handles all the corner cases.

54680cd

Attempting to test it by building and installing an RPM.

jcfr · 2018-07-30T20:39:55Z

src/python/CMakeLists.txt

@@ -28,6 +30,14 @@ set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fno-strict-aliasing")
 set (CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -fno-strict-aliasing")
 set (CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -fno-strict-aliasing")

+IF (NOT SKBUILD)
+    IF (${CMAKE_VERSION} VERSION_LESS "2.8.0")


Would it be sensible to bump the minimum required version fo CMake ?

@Conan-Kudo

Conan-Kudo · 2018-07-31T10:19:49Z

@dralley We can probably bump up to CMake 2.8.12.

* Added a setup.py and pyproject.toml * Made CMake config file changes to facilitate building in a different context * Updated gitignore

This commit introduces the option BUILD_LIBCREATEREPO_C_SHARED that is ON by default.

… install

…f relevant This is required to support importing the python module where the python interpreter is statically linked against the python library.

…rce directory This commit addresses the following error: ``` $ python setup.py egg_info running egg_info creating createrepo_c.egg-info writing dependency_links to createrepo_c.egg-info/dependency_links.txt writing top-level names to createrepo_c.egg-info/top_level.txt writing createrepo_c.egg-info/PKG-INFO writing manifest file 'createrepo_c.egg-info/SOURCES.txt' error: package directory 'createrepo_c' does not exist ``` It also updates the CMake install rules to ensure the __init__.py file and the python modules are installed in the appropriate package.

This commit generalizes the approach originally introduced in e880bf0 to prevent the development files from being installed when building the python package.

… install dir

This will ensure that executable will be available after installed the wheel. The approach adapted from scikit-build/cmake-python-distributions and scikit-build/ninja-python-distribution projects. For more details, see https://setuptools.readthedocs.io/en/latest/setuptools.html#automatic-script-creation

This is useful when developing locally.

dralley · 2018-08-02T16:16:53Z

Thank you again @jcfr , you've really gone above and beyond :)

I've added one more commit to automatically parse the version string from VERSION.cmake, so that it will not have to be changed in multiple places with every new release. And I will likely add some instructions to the README later today.

Other than that, @Conan-Kudo, @ignatenkobrain I think it's ready for review.

dralley · 2018-08-02T16:18:54Z

setup.py

+    # split on lines, remove empty lines
+    lines = filter(len, version_text.split('\n'))
+    # parse out digit characters from the line, convert to int
+    numbers = [int("".join(filter(str.isdigit, line))) for line in lines]


This could potentially be done "better" with regex, but I'm pretty weak with regex, and I think it's valid to assume there won't be numeric characters on each line that aren't part of the actual version number.

But I'm open to suggestions on how to do this better.

If it would be a pure python package, I would suggest to use python-versioneer

But in the case of createrepo_c, the project can be built either as a standalone project or python package, the version management needs to be available to both.

For now, I suggest to stick with your approach. Later after we standardize approaches like the one done here, this could be revisited.

jcfr · 2018-08-02T16:48:40Z

Thank you again @jcfr , you've really gone above and beyond :)

Glad to see that scikit-build is useful 😄

When the createrepo_c package will be ready, I was thinking we could write a blog featuring createrepo_c and scikit-build, would you be up for that ?

dralley · 2018-08-02T18:11:03Z

@jcfr I'm not a createrepo_c maintainer or anything, just a user who needed a feature, so I'll let the others weigh in on that one. I'm not sure I'm familiar enough with the project that I could do it justice and I wouldn't want to speak out of place or anything like that.

I wouldn't mind attempting to do so but writing is not really my forte.

jcfr · 2018-08-02T18:17:45Z

so I'll let the others weigh in on that one.

Sounds good.

just a user who needed a feature

That is great, i think you should still take part in telling the story. I think it illustrates how community, open-source and transparency lead to great outcome.

jcfr · 2018-08-02T20:57:59Z

README.md

+
+To create a binary "wheel" distribution, use:
+
+    python setup.py bdist_wheel


I think we should suggest the pip way instead:

pip wheel . -w dist

Are there any specific benefits? I've not seen this way before, but according to stack overflow and github issues, it can be fairly slow because it copies everything into a temp directory before doing the build.

Moving forward, the idea is to build python package using a standard approach that is independent from the build backend. The fact setuptools is used in an implementation details and we should try to move away from it, ideally i think the user experience should be the same for building wheels.

The other advantage is that it keeps the source tree clean of any artifact.

Timing wise, here is quick comparison for this project

$ mkvirtualenv -p python3.5 createrepo_c-pip-wheel $ time pip wheel . -w dist --no-cache-dir real 0m5.113s user 0m13.332s sys 0m1.104s

$ mkvirtualenv -p python3.5 createrepo_c-setup-bdist-wheel $ time bash -c "pip install -r requirements-dev.txt && python setup.py bdist_wheel" real 0m3.947s user 0m11.996s sys 0m1.180s

Fair points. The only objection I have is that w/ Pip v9 (which is what is currently installed on most distributions, including the newest Fedora and Ubuntu), you would also have to install the wheel package because that functionality isn't included by default. It looks like Pip v10+ does include it however.

I would probably err on the side of consistency, so if there's an analogous pip command for building sdists, we can use those. But otherwise I would probably stick with the "standard" way for now and update it later on.

so if there's an analogous pip command for building sdists

No

I would probably stick with the "standard" way for now and update it later on.

Agreed.

jcfr · 2018-08-02T21:00:13Z

README.md

+
+    python setup.py sdist
+
+Source distributions require the installer of the package to have all of the build dependencies installed on their system, since they compile the code during installation. Binary distributions are pre-compiled, but they are likely not portable between substantially different systems, e.g. Fedora and Ubuntu.


Source distributions require -> Installing source distributions require

jcfr · 2018-08-02T21:00:41Z

README.md

+
+Source distributions require the installer of the package to have all of the build dependencies installed on their system, since they compile the code during installation. Binary distributions are pre-compiled, but they are likely not portable between substantially different systems, e.g. Fedora and Ubuntu.
+
+If you install a source distribution, you will need


Look like this sentence is unfinished

dralley · 2018-08-22T13:08:02Z

edit: this is a nonissue, see below.

@jcfr For some reason libdrpm isn't being properly compiled statically, so building on a system where drpm-devel is present and then installing the resulting wheel on a system where it is not present results in an error when importing createrepo_c from a Python shell. It says it cannot find libdrpm.so.0.

(pulp) [vagrant@pulp3 createrepo_c]$ 
(pulp) [vagrant@pulp3 createrepo_c]$ ipython
Python 3.6.5 (default, Mar 29 2018, 18:20:46) 
Type 'copyright', 'credits' or 'license' for more information
IPython 6.5.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import createrepo_c
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-92f66d993759> in <module>()
----> 1 import createrepo_c

~/.virtualenvs/pulp/lib64/python3.6/site-packages/createrepo_c/__init__.py in <module>()
      6 import sys
      7 
----> 8 from . import _createrepo_c
      9 from ._createrepo_c import *
     10 

ImportError: libdrpm.so.0: cannot open shared object file: No such file or directory

It starts working again once I install drpm-devel

dralley · 2018-08-25T01:34:23Z

Since the Python bindings don't even expose support for deltarpm yet, I'm just going to disable it entirely - problem solved. See new commit.

Conan-Kudo · 2018-09-15T14:13:31Z

There are a couple of overall issues I have with this:

My understanding is that with something like pyproject.toml (PEP 518) and buildsys integration (PEP 517), it should be possible for CMake itself to drive the build. This feels completely backwards.
This package requires linking to librpm, so how do you deal with that problem?

dralley · 2018-09-15T15:27:46Z

Re: 1

Just to be clear, CMake is doing all of the build work. (Not sure if you were thinking otherwise). The only thing that scikit-build does is to wrap the existing setuptools / setup.py build hooks so that when something (pip, or the user directly) tries to build a package with setup.py, it calls CMake to handles the actual build, and then takes the resulting files and packages them up into a Python Wheel, which CMake doesn't know how to do.

Likewise, when you build createrepo_c as an RPM, the RPM tooling uses CMake to compile everything, and then packages the resulting files into an RPM. This is the same thing -- I don't understand why that's wrong or backwards?

edit: I address what I think you mean in another comment below.

With regards to PEP 517, PEP 517 is only "provisionally accepted" and it hasn't been implemented in Pip yet. Until it is (and becomes widespread enough that its presence on a user system can be assumed), everybody still has to use setup.py. Unfortunately it looks like the implementation effort is currently stalled out a bit because it's running on volunteer time, so it may take a while before it's ready, much less available on enough user systems to switch to.

Re: 2

Most Python packages that include compiled code (e.g. numpy, scipy, tensorflow) are targeted towards an environment called Manylinux. It's basically a CentOS 5 image provided by the Python Packaging Authority (PyPA) upon which they've built tooling which analyzes all the binaries for dynamically linked dependencies and uses PatchELF to inject them into the binaries themselves, effectively turning everything statically-linked. This allows you to build standalone binary Python packages that will work on any linux distro without modifying the actual build scripts to statically-link everything.

Unfortunately, since it's CentOS 5, the currently existing tooling can't be used to build createrepo_c since Glib 2.0 is too old and doesn't provide gchecksum.h. Fortunately, a new one is in progress based on CentOS 6, and that should work. Unfortunately, that project is also currently running on volunteer time and is stalled.

So for now the best we can do for now is to distribute a source package (sdist). When pip installs a sdist, it basically just unpacks the source, builds a bdist locally and installs that. This does require the user to have all of the correct build dependencies and libraries installed on their machine (cmake, librpm, libpython, etc.), but it would avoid all of the effort needed to build packages for every target environment. At some point, once the new Manylinux environment is ready, it would make sense to set up a CI pipeline to handle the process of building the binary packages for all of the supported enviornments. But that isn't an immediate concern (or possibility).

dralley · 2018-09-16T04:44:12Z

Re: 1,

Are you referring to how inside src/python/CMakeLists.txt it is checking whether it's building inside of a scikit-build context and doing slightly different things in that case? I can see how that might be confusing and look "backwards", but let me explain why it's better/necessary to be this way.

Looking at src/python/CMakeLists.txt line 1

We can't hardcode -DPYTHON_DESIRED=... because it has to work for both Python 2 and 3
If the user is using python2 setup.py bdist_wheel, or is installing it inside of a Python 2 virtual environment, then we automatically know we must build against Python 2, and likewise for Python 3.
If I'm installing an sdist from PyPI, I don't think those parameters can be specified ahead of time, and even if they can, they shouldn't be. The user needs to be able to just pip install createrepo_c and have everything just work.
- This is different from how it works with RPMs. If you want Python 3 bindings, you install python3-createrepo_c, and if you want Python 2 bindings, you install a completely separate package, python2-createrepo_c. The decision about how to build the package has been entirely removed from the user/developer-user and pushed onto the builder/maintainer, while the user just chooses which package to install. But in this case, there is no separate package that you can install or depend on -- there is just "createrepo_c", and the machinery has to figure out whether it needs to build for Python 2 or Python 3 on it's own.
Therefore it needs to be context-sensitive about whether setup.py is being executed in a Python 2 environment or a Python 3 environment, and pass that information down to CMake, which can then link against Python 2 libs or Python 3 libs respectively when building the package. Which is one of the things that scikit-build does.
So for this one specific case of building a Python package, we don't want to try to define the Python to build against up-front. So I stick it behind a conditional.

To explain the rest of those instances

The first one is basically the last bullet point mentioned above. PythonExtensions is a CMake module provided by scikit-build that uses contextual information exposed by scikit-build to figure out what Python libraries to target.
The last one is fixing an unsanitary operation -- in the case where we're building a Python package, we don't want it to install it to the local environment, we want it to just leave the files somewhere where the scikit-build / setuptools can find them, so that they can package them up into the wheel.
- To simplify this logic, what we could do is just change what $PYTHON_INSTALL_DIR is set to for building Python packages, instead of changing it down below.
The middle one was already there prior to this PR, but it's doing something we don't need to do in the Python packaging context, so we skip it.

I hope this explanation makes it sound more reasonable. It basically comes down to the fact that some things do need to be a little bit context sensitive for this specific use case, and the only way to access the context is to have something like scikit-build expose that information to CMake. I don't think PEP 517 avoids this situation either, just makes support for doing this sort of thing standardized and easier to implement.

Conan-Kudo · 2018-09-16T13:39:57Z

setup.py

+    version=version,
+    license='GPLv2',
+    author='RPM Software Management',
+    author_email='',


Email address is rpm-ecosystem@lists.rpm.org

Conan-Kudo · 2018-09-16T13:40:31Z

setup.py

+    name='createrepo_c',
+    description='C implementation of createrepo',
+    version=version,
+    license='GPLv2',


It is GPLv2+

Conan-Kudo · 2018-09-16T13:41:45Z

src/CMakeLists.txt

@@ -110,16 +115,34 @@ CONFIGURE_FILE("deltarpms.h.in" "${CMAKE_CURRENT_SOURCE_DIR}/deltarpms.h" @ONLY)
 IF (CMAKE_SIZEOF_VOID_P MATCHES "8")
    SET (LIB_SUFFIX "64")
 ENDIF (CMAKE_SIZEOF_VOID_P MATCHES "8")
+
 SET (LIB_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX}")


Can we just go ahead and change this to use GNUInstallDirs? We're already saying we require at least CMake 2.8, right?

dralley · 2018-09-16T15:00:12Z

@Conan-Kudo updated

dmach · 2018-11-19T15:17:01Z

I've tested that createrepo_c builds fine with this patch.
I'm merging the PR.
We can solve additional issues as new PRs.

Please note that DNF team has no intention to manage createrepo_c in pypi.

dralley force-pushed the python-pkg branch from d7ceb97 to e880bf0 Compare July 30, 2018 03:45

dralley changed the title ~~Python pkg~~ Enable building Python packages for PyPI distribution Jul 30, 2018

dralley mentioned this pull request Jul 30, 2018

Package createrepo_c for PyPI #99

Closed

ignatenkobrain reviewed Jul 30, 2018

View reviewed changes

dralley force-pushed the python-pkg branch 2 times, most recently from 4e0134d to da85933 Compare July 30, 2018 12:41

dralley commented Jul 30, 2018

View reviewed changes

jcfr reviewed Jul 30, 2018

View reviewed changes

dralley changed the title ~~Enable building Python packages for PyPI distribution~~ [WIP] Enable building Python packages for PyPI distribution Jul 31, 2018

dralley changed the title ~~[WIP] Enable building Python packages for PyPI distribution~~ [work in progress] Enable building Python packages for PyPI distribution Jul 31, 2018

dralley force-pushed the python-pkg branch from 931ab3c to e65a9e2 Compare July 31, 2018 14:38

dralley and others added 13 commits July 31, 2018 10:47

Add the capability to build Python (PyPI) packages directly.

527ca7a

* Added a setup.py and pyproject.toml * Made CMake config file changes to facilitate building in a different context * Updated gitignore

cmake: Support building libcreaterepo_c statically

4311a8e

This commit introduces the option BUILD_LIBCREATEREPO_C_SHARED that is ON by default.

cmake: Include OPENSSL_INCLUDE_DIR to support building against custom…

1227830

… install

cmake: Ensure _createrepo_c is weakly linked against python library i…

6f77806

…f relevant This is required to support importing the python module where the python interpreter is statically linked against the python library.

setup.py: Set BUILD_LIBCREATEREPO_C_SHARED to OFF

a4eee6b

Build and distribute the binaries, too.

9280ebe

setup.py: Set ENABLE_BASHCOMP option instead of checking for SKBUILD

fe5a306

cmake: Introduce CREATEREPO_C_INSTALL_MANPAGES option

717b965

cmake: Introduce CREATEREPO_C_INSTALL_DEVELOPMENT option

399975f

This commit generalizes the approach originally introduced in e880bf0 to prevent the development files from being installed when building the python package.

cmake: Introduce BIN_INSTALL_DIR to allow customization of executable…

cdf910c

… install dir

Add requirements-dev.txt

3b67fc3

This is useful when developing locally.

Add code to setup.py to parse version from VERSION.cmake

5d6c5e9

dralley commented Aug 2, 2018

View reviewed changes

dralley force-pushed the python-pkg branch from 5836ce9 to 954607a Compare August 2, 2018 20:43

jcfr reviewed Aug 2, 2018

View reviewed changes

dralley force-pushed the python-pkg branch 2 times, most recently from 05f424e to 22fa7c6 Compare August 2, 2018 21:16

README snippet

c018c70

dralley force-pushed the python-pkg branch from 22fa7c6 to c018c70 Compare August 2, 2018 21:47

Use splitlines() instead of split()

5a87e04

Python bindings don't support deltarpm; disable it

0cb6fc4

Conan-Kudo requested changes Sep 16, 2018

View reviewed changes

Fix package metadata

fe04253

dralley force-pushed the python-pkg branch 2 times, most recently from 1a5935c to c510f2e Compare September 16, 2018 18:03

Utilize GNUInstallDirs

2f71436

dralley force-pushed the python-pkg branch from c510f2e to 2f71436 Compare September 16, 2018 18:12

dmach merged commit 403bf3f into rpm-software-management:master Nov 19, 2018

dralley deleted the python-pkg branch November 26, 2018 22:32

dralley mentioned this pull request Nov 30, 2018

Remove createrepo_c build docs pulp/pulp_rpm#1230

Merged


		To create a binary "wheel" distribution, use:

		python setup.py bdist_wheel


		python setup.py sdist

		Source distributions require the installer of the package to have all of the build dependencies installed on their system, since they compile the code during installation. Binary distributions are pre-compiled, but they are likely not portable between substantially different systems, e.g. Fedora and Ubuntu.


		Source distributions require the installer of the package to have all of the build dependencies installed on their system, since they compile the code during installation. Binary distributions are pre-compiled, but they are likely not portable between substantially different systems, e.g. Fedora and Ubuntu.

		If you install a source distribution, you will need

Enable building Python packages for PyPI distribution #103

Enable building Python packages for PyPI distribution #103

Conversation

dralley commented Jul 30, 2018 • edited Loading

Cmake build system changes

Python specific changes

dralley commented Jul 30, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcfr commented Jul 30, 2018 • edited Loading

dralley commented Jul 30, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dralley Jul 30, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dralley Jul 31, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcfr Jul 31, 2018 • edited Loading

Choose a reason for hiding this comment

Conan-Kudo Jul 31, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dralley Jul 31, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Conan-Kudo commented Jul 31, 2018

dralley commented Aug 2, 2018 • edited Loading

dralley Aug 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcfr commented Aug 2, 2018

dralley commented Aug 2, 2018 • edited Loading

jcfr commented Aug 2, 2018

Choose a reason for hiding this comment

dralley Aug 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dralley commented Aug 22, 2018 • edited Loading

dralley commented Aug 25, 2018

Conan-Kudo commented Sep 15, 2018

dralley commented Sep 15, 2018 • edited Loading

dralley commented Sep 16, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dralley commented Sep 16, 2018

dmach commented Nov 19, 2018

dralley commented Jul 30, 2018 •

edited

Loading

jcfr commented Jul 30, 2018 •

edited

Loading

dralley Jul 30, 2018 •

edited

Loading

dralley Jul 31, 2018 •

edited

Loading

jcfr Jul 31, 2018 •

edited

Loading

Conan-Kudo Jul 31, 2018 •

edited

Loading

dralley Jul 31, 2018 •

edited

Loading

dralley commented Aug 2, 2018 •

edited

Loading

dralley Aug 2, 2018 •

edited

Loading

dralley commented Aug 2, 2018 •

edited

Loading

dralley Aug 2, 2018 •

edited

Loading

dralley commented Aug 22, 2018 •

edited

Loading

dralley commented Sep 15, 2018 •

edited

Loading

dralley commented Sep 16, 2018 •

edited

Loading