Hello
I am trying to package mkdocs , it si similar to sphinx, but not as powerfull, but can be very usefull.
https://bugzilla.redhat.com/show_bug.cgi?id=1230963
I am packaging only one version build with phyton 3 and naming it mkdocs, but I am not sure it is better to name this docs as python3-mkdocs and build python-mkdocs also.
I think than build python-mkdocs and python3-mkdocs with Provides: mkdocs in the Python3 package can work.
Really I not sure how to proceed in this case, but I think if it would be good to have both versions available for booth Python releases and provide by default the version for Python 3 when a user install mkdocs with dnf.
William Moreno Reyes http://about.me/williamjmorenor
On Fri, Jun 12, 2015 at 10:15:58AM -0600, William Moreno wrote:
I am packaging only one version build with phyton 3 and naming it mkdocs, but I am not sure it is better to name this docs as python3-mkdocs and build python-mkdocs also.
As I understand the guidelines, the python-prefix convention applies to _python modules_ — libraries intended to be imported by other applications. If this is, instead, an application which just happens to be written in Python, the prefix doesn't make any sense to me.
Really I not sure how to proceed in this case, but I think if it would be good to have both versions available for booth Python releases and provide by default the version for Python 3 when a user install mkdocs with dnf.
What would be the advantage of having two versions?
On Fri, Jun 12, 2015 at 12:39:50PM -0400, Matthew Miller wrote:
On Fri, Jun 12, 2015 at 10:15:58AM -0600, William Moreno wrote:
I am packaging only one version build with phyton 3 and naming it mkdocs, but I am not sure it is better to name this docs as python3-mkdocs and build python-mkdocs also.
If you default to the py3 version, I'd suggest you use mkdocts-py2 or python2-mkdocs for the py2 version.
Note: you could add a Provides: python3-mkdocs to the main package or vice versa, make the package be named python3-mkdocs and add a Provides: mkdocs if the usual name of the application (the one people will use when looking for it) is indeed mkdocs (cf also the remark from Matthew I trimed down from this email).
Really I not sure how to proceed in this case, but I think if it would be good to have both versions available for booth Python releases and provide by default the version for Python 3 when a user install mkdocs with dnf.
What would be the advantage of having two versions?
Well the python universe is still very much py2 but the future is py3 and we should aim for it, so it makes sense to have both :)
Pierre
On Fri, Jun 12, 2015 at 06:59:04PM +0200, Pierre-Yves Chibon wrote:
What would be the advantage of having two versions?
Well the python universe is still very much py2 but the future is py3 and we should aim for it, so it makes sense to have both :)
Well, sure, for modules, but from the web page, this looks like an end-user application. Why would anyone but its own developers care which Python it is written in (as long as it's a supported version, of course)?
On Fri, Jun 12, 2015 at 01:03:56PM -0400, Matthew Miller wrote:
On Fri, Jun 12, 2015 at 06:59:04PM +0200, Pierre-Yves Chibon wrote:
What would be the advantage of having two versions?
Well the python universe is still very much py2 but the future is py3 and we should aim for it, so it makes sense to have both :)
Well, sure, for modules, but from the web page, this looks like an end-user application. Why would anyone but its own developers care which Python it is written in (as long as it's a supported version, of course)?
I can see the argument and that's a thought worth having :) You could indeed only have a single py3 version.
Eventually you could always re-introduce the py2 if someone was to complain that it's not there (because the're building on it or for whatever reason).
Pierre
2015-06-12 11:19 GMT-06:00 Pierre-Yves Chibon pingou@pingoured.fr:
On Fri, Jun 12, 2015 at 01:03:56PM -0400, Matthew Miller wrote:
On Fri, Jun 12, 2015 at 06:59:04PM +0200, Pierre-Yves Chibon wrote:
What would be the advantage of having two versions?
Well the python universe is still very much py2 but the future is py3 and we should aim for it, so it makes sense to have both :)
Well, sure, for modules, but from the web page, this looks like an end-user application. Why would anyone but its own developers care which Python it is written in (as long as it's a supported version, of course)?
I can see the argument and that's a thought worth having :) You could indeed only have a single py3 version.
Eventually you could always re-introduce the py2 if someone was to complain that it's not there (because the're building on it or for whatever reason).
Thanks all for the feedback
I will keep olny the python3 package and if someone ask for the python2 build will make the python2 build as subpackage.
By the way it will be nice if someone take the review of the package :)
packaging@lists.fedoraproject.org