Re: [Marketing] Help Getting Started - Python Talking Points and Meetings
Hi James, On 03/18/2016 03:41 PM, James Bishop wrote: Hi Justin The biggest question I have right now is whether I need to be a part of the marketing group to log in to the other sites. I have an FAS account, and the CLA has been signed, but when I try to sign on to the TRAC, I get a "you are not allowed here" message, and the wiki tells me that my login info is bad. Yes, the best place to add some more info would definitely be the Trac. The reason why you are unable to log in is because there are some temporary limitations added to the wiki and all Trac instances to block a recent bout with spambots attacking both services. You should stop by in #fedora-admin and ping either puiterwijk or nirik to add your FAS account to the antispam-ack group. This limitation is actually due to be lifted sometime today, but if you are unable to log in still, please let the folks know there and they can help get you logged in! As for what I <3 about Python in Fedora, I would say that it comes down to the fact that the packages I need are in the repos, so I can manage everything with one package manager, and the ease of transition to RHEL instances. That said, I didn't really choose Fedora as a Python developer, but as someone who appreciates free software and Fedora's stance on it. That kind of feedback is definitely good to hear. Whatever your experience or profession is, adding that in somewhere for consideration should definitely happen. Let's see if we can get your Trac permissions resolved and then add that to the ticket. -- Cheers, Justin W. Flory jflo...@gmail.com signature.asc Description: OpenPGP digital signature ___ python-devel mailing list python-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: Inconsistencies in the Fedora Packaging Guidelines for Python
On Mon, Mar 21, 2016 at 05:35:03PM -0400, Neal Gompa wrote:
> On Mon, Mar 21, 2016 at 3:55 PM, Miro Hrončok wrote:
> > On 21.3.2016 20:13, Zbigniew Jędrzejewski-Szmek wrote:
> >>
> >> On Mon, Mar 21, 2016 at 06:46:00PM -, Tomas Orsava wrote:
> >>>
> >>> Since the spec file does package both p2 and p3 versions of the
> >>> executable
> >>
> >>
> >> There's a difference between *modules* (in the Python sense,
> >> i.e. Python libraries) and *executables*. We almost always want
> >> to provide modules for both Python versions, but executables
> >> only rarely so.
> >>
> >> The example spec file does *not* package both versions of the
> >> executable.
> >
> >
> > Yes, it does.
Ah, OK. It didn't at some point and I didn't check.
It seems that the Guidelines:Python page could still use some
editing. I think most of the info is there, but it's not very clear.
In particular, the multiple-executables case is again very prominent
(as this thread shows), and it's really applicable to a miniscule
percentage of packages (literally: sphinx, pytest, nosetest, a bunch
of python development and installation tools. There's a spattering
of other random packages, which might be mistakes. E.g. python-nibabel
also provides versioned executables, but that I don't think there's a
good reason for that). The way that Guidelines are written only serves
to confuse packagers.
> > %files -n python2-%{srcname}
> > %license COPYING
> > %doc README.rst
> > %{python2_sitelib}/*
> > %{_bindir}/sample-exec-2.7< HERE
> >
> > %files -n python3-%{srcname}
> > %license COPYING
> > %doc README.rst
> > %{python3_sitelib}/*
> > %{_bindir}/sample-exec< HERE
> > %{_bindir}/sample-exec-3.4< HERE
> >
> > https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
>
> I would suggest that the unversioned binary shouldn't necessarily be
> part of a versioned python package (like pythonX-), but I
> guess this is something that people expect these days anyway...
The alternative would to add yet another subpackage. Most of the
time that would be overkill. In the common case it works just fine
to put the binaries in py2 or py3 subpackage.
Zbyszek
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: Inconsistencies in the Fedora Packaging Guidelines for Python
On Mon, Mar 21, 2016 at 3:55 PM, Miro Hrončok wrote:
> On 21.3.2016 20:13, Zbigniew Jędrzejewski-Szmek wrote:
>>
>> On Mon, Mar 21, 2016 at 06:46:00PM -, Tomas Orsava wrote:
>>>
>>> Since the spec file does package both p2 and p3 versions of the
>>> executable
>>
>>
>> There's a difference between *modules* (in the Python sense,
>> i.e. Python libraries) and *executables*. We almost always want
>> to provide modules for both Python versions, but executables
>> only rarely so.
>>
>> The example spec file does *not* package both versions of the
>> executable.
>
>
> Yes, it does.
>
> %files -n python2-%{srcname}
> %license COPYING
> %doc README.rst
> %{python2_sitelib}/*
> %{_bindir}/sample-exec-2.7< HERE
>
> %files -n python3-%{srcname}
> %license COPYING
> %doc README.rst
> %{python3_sitelib}/*
> %{_bindir}/sample-exec< HERE
> %{_bindir}/sample-exec-3.4< HERE
>
> https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
>
I would suggest that the unversioned binary shouldn't necessarily be
part of a versioned python package (like pythonX-), but I
guess this is something that people expect these days anyway...
--
真実はいつも一つ！/ Always, there's only one truth!
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: Inconsistencies in the Fedora Packaging Guidelines for Python
On 21.3.2016 20:13, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Mar 21, 2016 at 06:46:00PM -, Tomas Orsava wrote:
Since the spec file does package both p2 and p3 versions of the executable
There's a difference between *modules* (in the Python sense,
i.e. Python libraries) and *executables*. We almost always want
to provide modules for both Python versions, but executables
only rarely so.
The example spec file does *not* package both versions of the
executable.
Yes, it does.
%files -n python2-%{srcname}
%license COPYING
%doc README.rst
%{python2_sitelib}/*
%{_bindir}/sample-exec-2.7< HERE
%files -n python3-%{srcname}
%license COPYING
%doc README.rst
%{python3_sitelib}/*
%{_bindir}/sample-exec< HERE
%{_bindir}/sample-exec-3.4< HERE
https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: Inconsistencies in the Fedora Packaging Guidelines for Python
On Mon, Mar 21, 2016 at 06:46:00PM -, Tomas Orsava wrote: > Since the spec file does package both p2 and p3 versions of the executable There's a difference between *modules* (in the Python sense, i.e. Python libraries) and *executables*. We almost always want to provide modules for both Python versions, but executables only rarely so. The example spec file does *not* package both versions of the executable. Zbyszek ___ python-devel mailing list python-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: Inconsistencies in the Fedora Packaging Guidelines for Python
> But this section explicitly only covers the rare case where a py2 and > py3 version of something provide _different_ functionality. > The example spec is for the normal case. That's why it's up above the > "Avoiding collisions between the python 2 and python 3 stacks" section. > That section covers a specific case which applies to only a few packages. Well, here's what the guidelines say about the normal case: "If the executables provide the same functionality independent of whether they are run on top of Python 2 or Python 3, then only the Python 3 version of the executable should be packaged." Since the spec file does package both p2 and p3 versions of the executable, I infer that we are indeed dealing with the case where it is beneficial to package both p2 and p3 version of the executable, in which case my first post applies and the example is wrong. So in summary, either the example is wrong by packaging both p2 and p3 versions of the executable, or it is wrong by packaging the p3 version of the executable as the default one. ___ python-devel mailing list python-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Re: Inconsistencies in the Fedora Packaging Guidelines for Python
> "TO" == Tomas Orsava writes: TO> Hi, according to the "Fedora Packaging Guidelines for Python" [0] TO> the "Example common spec file" [1] contained in those very same TO> guidelines is wrong. I think you misunderstand. TO> Specifically, the section "Naming" [2] in the guidelines says the TO> following: But this section explicitly only covers the rare case where a py2 and py3 version of something provide _different_ functionality. The example spec is for the normal case. That's why it's up above the "Avoiding collisions between the python 2 and python 3 stacks" section. That section covers a specific case which applies to only a few packages. - J< ___ python-devel mailing list python-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
Inconsistencies in the Fedora Packaging Guidelines for Python
Hi,
according to the "Fedora Packaging Guidelines for Python" [0] the "Example
common spec file" [1] contained in those very same guidelines is wrong.
Specifically, the section "Naming" [2] in the guidelines says the following:
(1) "Both python 2 and python 3 variants must provide symlinks with a '-X' and
'-X.Y' suffix (python runtime major version, or python runtime major.minor
version), unless upstream already provides appropriately versioned executables
without the dash."
(2) "The unversioned executable must be the python2 version."
(3) "For example, the python3 version of "coverage" must ship executables
/usr/bin/coverage-3 and /usr/bin/coverage-3.4 (assuming python3 is currently
version 3.4), while the python2 version must provide /usr/bin/coverage,
/usr/bin/coverage-2 and /usr/bin/coverage-2.7 (assuming python2 version 2.7)."
So given that, the "Example common spec file" [1] has the following problems:
* The unversioned executable ('%{_bindir}/sample-exec') is provided by the
python3- subpackage instead of the python2- subpackage.
* In the %install section, the order of execution of the %py2_install and
%py3_install macros is wrong, since it leads to python3- subpackage providing
the unversioned executable. The comment in the section should be modified
accordingly as well.
* Neither python2- nor python3- subpackages provide symlinks to the '-X'
suffix, i.e. 'sample-exec-2' and 'sample-exec-3'
[0] https://fedoraproject.org/wiki/Packagingython
[1] https://fedoraproject.org/wiki/Packagingython#Example_common_spec_file
[2] https://fedoraproject.org/wiki/Packagingython#Naming
Thank you for your time,
Tomas Orsava
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
