<feed xmlns='http://www.w3.org/2005/Atom'>
<title>packages/lang/python/python3/files/python3-package.mk, branch openwrt-18.06</title>
<subtitle>Community maintained packages for OpenWrt</subtitle>
<id>http://x-nagi.com/cgit/packages/atom?h=openwrt-18.06</id>
<link rel='self' href='http://x-nagi.com/cgit/packages/atom?h=openwrt-18.06'/>
<link rel='alternate' type='text/html' href='http://x-nagi.com/cgit/packages/'/>
<updated>2018-01-10T21:01:51Z</updated>
<entry>
<title>python,python3: export mk files outside of python package dirs</title>
<updated>2018-01-10T21:01:51Z</updated>
<author>
<name>Alexandru Ardelean</name>
<email>ardeleanalex@gmail.com</email>
</author>
<published>2018-01-10T07:29:41Z</published>
<link rel='alternate' type='text/html' href='http://x-nagi.com/cgit/packages/commit/?id=ccdc6bc530444283a510ceb6a50878493fe356f2'/>
<id>urn:sha1:ccdc6bc530444283a510ceb6a50878493fe356f2</id>
<content type='text'>
Since `lang/python` is it's own folder of Python packages
(for both Python 2 &amp; 3), and these build rules are needed
in a lot of packages [especially Python packages],
putting them here makes sense architecturally,
to be shared.

This also helps get rid of the `include_mk` construct
which relies on OpenWrt core to provide, and seems
like a broken design idea that has persisted for a while.
Reason is: it requires that Python 2/3 be built to provide
these mk files for other Python packages,
which seems like a bad idea.

Long-term, there could be an issue where some other feeds
would require these mk files [e.g. telephony] for
some Python packages.
We'll see how we handle this a bit later.

For now we limit this to this feed.

Signed-off-by: Alexandru Ardelean &lt;ardeleanalex@gmail.com&gt;
</content>
</entry>
<entry>
<title>python,python3: undo egg-info removal</title>
<updated>2018-01-08T09:26:54Z</updated>
<author>
<name>Jeffery To</name>
<email>jeffery.to@gmail.com</email>
</author>
<published>2018-01-08T09:26:54Z</published>
<link rel='alternate' type='text/html' href='http://x-nagi.com/cgit/packages/commit/?id=c5cbd44cea99c5abe7317833d0671828abb6e108'/>
<id>urn:sha1:c5cbd44cea99c5abe7317833d0671828abb6e108</id>
<content type='text'>
This reverts commits 4333d1dcbfd67dde4ca7d08717bc345cc424fbf8 and
074d2863be48c1a9093fffcda91f7a328bc7d0cb, making Python packages
discoverable again by pkg_resources.

Fixes #5361.

Signed-off-by: Jeffery To &lt;jeffery.to@gmail.com&gt;
</content>
</entry>
<entry>
<title>python,python3: add option to keep egg-info dirs for python packages</title>
<updated>2017-10-03T07:40:26Z</updated>
<author>
<name>Alexandru Ardelean</name>
<email>ardeleanalex@gmail.com</email>
</author>
<published>2017-10-02T12:43:52Z</published>
<link rel='alternate' type='text/html' href='http://x-nagi.com/cgit/packages/commit/?id=074d2863be48c1a9093fffcda91f7a328bc7d0cb'/>
<id>urn:sha1:074d2863be48c1a9093fffcda91f7a328bc7d0cb</id>
<content type='text'>
That way some python packages can choose
to keep their egg-info dirs, if they want to, or they're needed.

Signed-off-by: Alexandru Ardelean &lt;ardeleanalex@gmail.com&gt;
</content>
</entry>
<entry>
<title>python,python3: add host python pip install support</title>
<updated>2017-07-19T13:50:25Z</updated>
<author>
<name>Alexandru Ardelean</name>
<email>ardeleanalex@gmail.com</email>
</author>
<published>2017-07-19T07:19:10Z</published>
<link rel='alternate' type='text/html' href='http://x-nagi.com/cgit/packages/commit/?id=612c53fc6c3d9ba2a57f7329baf055f1d59a9246'/>
<id>urn:sha1:612c53fc6c3d9ba2a57f7329baf055f1d59a9246</id>
<content type='text'>
To install Python packages host side, that
may be needed for a build.

The intent, is to try to reduce host-side Python
packages being installed via LEDE/OpenWrt build system.
Because those seem like a pain to maintain.

The idea is adapted from Yousong's `python-packages`
package.

Signed-off-by: Alexandru Ardelean &lt;ardeleanalex@gmail.com&gt;
</content>
</entry>
<entry>
<title>python,python3: define PyBuild/Compile &amp; Py3Build/Compile</title>
<updated>2017-07-07T15:07:10Z</updated>
<author>
<name>Alexandru Ardelean</name>
<email>ardeleanalex@gmail.com</email>
</author>
<published>2017-07-04T17:58:37Z</published>
<link rel='alternate' type='text/html' href='http://x-nagi.com/cgit/packages/commit/?id=8db8c927edb277f7ff2c6147530cd28f1e4c5d8c'/>
<id>urn:sha1:8db8c927edb277f7ff2c6147530cd28f1e4c5d8c</id>
<content type='text'>
Similar to LEDE/OpenWrt's Build/Compile/Default rule,
and other similarities like this.

This should allow Python packages to define
PyBuild/Compile rules to do specific stuff per
package.

The advantage of using these (over just overriding
Build/Compile) is the VARIANT mechanism that is
in place to support packaging both for Python &amp; Python3.

So, PyBuild/Compile will get picked up for the Python
variant build, and Py3Build/Compile will get picked
up for the Python3 variant build.

Signed-off-by: Alexandru Ardelean &lt;ardeleanalex@gmail.com&gt;
</content>
</entry>
<entry>
<title>python,python3: allow python packages to override Package/&lt;pkg&gt;/install rule</title>
<updated>2017-05-19T14:16:39Z</updated>
<author>
<name>Alexandru Ardelean</name>
<email>ardeleanalex@gmail.com</email>
</author>
<published>2017-05-19T14:16:38Z</published>
<link rel='alternate' type='text/html' href='http://x-nagi.com/cgit/packages/commit/?id=b9d88065f519583841602170a0f2827fb5ce02f3'/>
<id>urn:sha1:b9d88065f519583841602170a0f2827fb5ce02f3</id>
<content type='text'>
Python packages try to enforce their own.
For some cases this may not be desired.

Signed-off-by: Alexandru Ardelean &lt;ardeleanalex@gmail.com&gt;
</content>
</entry>
<entry>
<title>python packages: move all things python under lang/python</title>
<updated>2017-05-17T13:51:14Z</updated>
<author>
<name>Alexandru Ardelean</name>
<email>ardeleanalex@gmail.com</email>
</author>
<published>2017-05-17T13:45:48Z</published>
<link rel='alternate' type='text/html' href='http://x-nagi.com/cgit/packages/commit/?id=68312f49c0b4456e665ed438a86a44738caa765a'/>
<id>urn:sha1:68312f49c0b4456e665ed438a86a44738caa765a</id>
<content type='text'>
I admit this may be be a bit aggressive, but the lang
folder is getting cluttered/filled up with Python, PHP, Perl,
Ruby, etc. packages.

Makes sense to try to group them into per-lang folders.

I took the Pythons.

Signed-off-by: Alexandru Ardelean &lt;ardeleanalex@gmail.com&gt;
</content>
</entry>
</feed>
