Re: [Python-Dev] Binary CPython distribution for Linux
- Original Message - > While much of the opposition to dropping Python <2.7 stems from the RHEL > community (they still have 2.4 in extended support and 2.7 wasn't in a > release until a few weeks ago), a common objection from the users is "I > can't install a different Python" or "it's too difficult to install a > different Python." The former is a legit complaint - if you are on > shared hosting and don't have root, as easy as it is to add an alternate > package repository that provides 2.7 (or newer), you don't have the > permissions so you can't do it. It's not true that 2.7 wasn't released until few weeks ago. It was released few weeks ago as part of RHEL 7, but Red Hat has been shipping Red Hat Software Collections (RHSCL) 1.0, that contain Python 2.7 and Python 3.3, for almost a year now [1] - RHSCL is installable on RHEL 6; RHSCL 1.1 (also with 2.7 and 3.3) has been released few weeks ago and is supported on RHEL 6 and 7. Also, these collections now have their community rebuilds at [2], so you can just download them without needing to talk to Red Hat at all. But yeah, these are all RPMs, so you have to be root to install them. > I'd like to propose a solution to this problem: a pre-built distribution > of CPython for Linux available via www.python.org in the list of > downloads for a particular release [5]. This distribution could be > downloaded and unarchived into the user's home directory and users could > start running it immediately by setting an environment variable or two, > creating a symlink, or even running a basic installer script. This would > hopefully remove the hurdles of obtaining a (sane) Python distribution > on Linux. This would allow projects to more easily drop end-of-life > Python versions and would speed adoption of modern Python, including > Python 3 (because porting is much easier if you only have to target 2.7). > > I understand there may be technical challenges with doing this for some > distributions and with producing a universal binary distribution. I > would settle for a binary distribution that was targeted towards RHEL > users and variant distros, as that is the user population that I > perceive to be the most conservative and responsible for holding modern > Python adoption back. Speaking with my Fedora/RHEL/RHSCL Python maintainer's hat on, prebuilding Python is not as easy task as it may seem :) Someone has to write the build scripts (e.g. sort of specfile, but rpm/specfile wouldn't really work for you, since you want to install in user's home dirs). Someone has to update them when new Python comes out, so in the worst case you end up with slightly different build scripts for different versions of Python. Someone has to do rebuilds when there is CVE. Or a bug. Or a user requests a feature that makes sense. Someone has to do that for *each packaged version* - and each packaged version needs to be maintained for some amount of time so that it all actually makes sense. Maintaining a prebuilt distribution of Python is a time consuming task even if you do it just for one Linux distro. If you want to maintain a *universal* prebuilt Python distribution, then you'll find out that it's a) undoable b) consumes so many resources and it's so fragile, that it's probably not worth it. You could just bundle all Python dependencies into your distribution to make it "easier", but that would just make the result grow in size (perhaps significantly) and you would then also need to update/bugfix/securityfix the bundled dependencies (which would consume even more time). Please don't take this as a criticism of your ideas, I see what you're trying to solve. I just think the way you're trying to solve it is unachievable or would consume so much community resources, that it would end up unmaintained and buggy most of the time. -- Regards, Bohuslav "Slavek" Kabrda. [1] http://developerblog.redhat.com/2013/09/12/rhscl1-ga/ [2] https://www.softwarecollections.org/en/scls/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 394 - Clarification of what "python" command should invoke
Hi, as Fedora is getting closer to having python3 as a default, I'm being more and more asked by Fedora users/contributors what'll "/usr/bin/python" invoke when we achieve this (Fedora 22 hopefully). So I was rereading PEP 394 and I think I need a small clarification regarding two points in the PEP: - "for the time being, all distributions should ensure that python refers to the same target as python2." - "Similarly, the more general python command should be installed whenever any version of Python is installed and should invoke the same version of Python as either python2 or python3." The important word in the second point is, I think, *whenever*. Trying to apply these two points to Fedora 22 situation, I can think of several approaches: - /usr/bin/python will always point to python3 (seems to go against the first mentioned PEP recommendation) - /usr/bin/python will always point to python2 (seems to go against the second mentioned PEP recommendation, there is no /usr/bin/python if python2 is not installed) - /usr/bin/python will point to python3 if python2 is not installed, else it will point to python2 (inconsistent; also the user doesn't know he's running and what libraries he'll be able to import - the system can have different sets of python2-* and python3-* extension modules installed) - there will be no /usr/bin/python (goes against PEP and seems just wrong) I'd really appreciate upstream guidance and perhaps a PEP clarification for distributions that ship both python2 and python3, but can live without python2 (and are not Arch :)). Thanks a lot! -- Regards, Slavek Kabrda ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke
- Original Message - > On 19 Sep 2014 17:38, "Bohuslav Kabrda" < bkab...@redhat.com > wrote: > > - "Similarly, the more general python command should be installed whenever > > any version of Python is installed and should invoke the same version of > > Python as either python2 or python3." > > > > The important word in the second point is, I think, *whenever*. Trying to > > apply these two points to Fedora 22 situation, I can think of several > > approaches: > > - /usr/bin/python will always point to python3 (seems to go against the > > first mentioned PEP recommendation) > > - /usr/bin/python will always point to python2 (seems to go against the > > second mentioned PEP recommendation, there is no /usr/bin/python if > > python2 is not installed) > I think this is what should happen, and the PEP is currently wrong. When > writing the PEP, I don't think we accounted properly for the case where the > "system Python" has migrated to Python 3, but the "default Python for end > user scripts that don't specify otherwise" is still Python 2 (which is the > migration strategy both Fedora and Ubuntu are adopting). Thanks, that was my thinking, too. > How does this sound as a possible revised recommendation (keep in mind I > haven't checked this against the larger context yet): > "The more general python command should only be installed whenever the > corresponding version of Python is installed (whether python2 or python3)." It seems to me that it is a bit unclear what "corresponding" is. Would it make sense to explicitly say that "python" command should be installed whenever the distro-chosen default system Python is installed? > Regards, > Nick. Thanks a lot -- Regards, Slavek Kabrda ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke
- Original Message - > On 20 September 2014 00:23, Donald Stufft wrote: > > > > On Sep 19, 2014, at 10:16 AM, Barry Warsaw wrote: > > > > If the user wants to invoke Python 3, it's not hard to type 'python3' and I > > think that's the message we should be spreading. That already seems pretty > > ingrained in user habits afaict. > > > > > > My biggest problem with ``python3``, is what happens after 3.9. I know > > Guido > > doesn’t particularly like two digit version numbers and it’s been suggested > > on > > this list that instead of 3.10 we’re likely to move directly into 4.0 > > regardless of > > if it’s a “big” change or not. > > FWIW, I think we actually do this better on Windows these days, where > PEP 397 made "py" a switchable entry point. I'd like to bring the same > scheme to POSIX systems at some point, but that's a *long* way down > the todo list (like, so far down I can't even see it any more). I'd be > willing to review proposals, though :) We did a similar thing with Ruby in Fedora, it's called Rubypick [1]. Is that a direction worth pursuing? Also, what is actually result of this thread? AFAICS the PEP still hasn't changed. IMO when there's only python3 installed, there should be no /usr/bin/python, which also seems to be aligned with what Guido says. Would it be possible to update the PEP accordingly? Thanks! > Cheers, > Nick. -- Regards, Slavek Kabrda [1] https://github.com/fedora-ruby/rubypick ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke
- Original Message - > On 30 September 2014 20:13, Bohuslav Kabrda wrote: > > - Original Message - > >> On 20 September 2014 00:23, Donald Stufft wrote: > >> > > >> > On Sep 19, 2014, at 10:16 AM, Barry Warsaw wrote: > >> > > >> > If the user wants to invoke Python 3, it's not hard to type 'python3' > >> > and I > >> > think that's the message we should be spreading. That already seems > >> > pretty > >> > ingrained in user habits afaict. > >> > > >> > > >> > My biggest problem with ``python3``, is what happens after 3.9. I know > >> > Guido > >> > doesn’t particularly like two digit version numbers and it’s been > >> > suggested > >> > on > >> > this list that instead of 3.10 we’re likely to move directly into 4.0 > >> > regardless of > >> > if it’s a “big” change or not. > >> > >> FWIW, I think we actually do this better on Windows these days, where > >> PEP 397 made "py" a switchable entry point. I'd like to bring the same > >> scheme to POSIX systems at some point, but that's a *long* way down > >> the todo list (like, so far down I can't even see it any more). I'd be > >> willing to review proposals, though :) > > > > We did a similar thing with Ruby in Fedora, it's called Rubypick [1]. Is > > that a direction worth pursuing? > > Yes, I think so. The general idea would be to take the PEP 397 > launcher CLI and propose a similar API for *nix systems: > https://docs.python.org/3/using/windows.html#python-launcher-for-windows Thanks, I'll try looking into this if I get some free time... > > Also, what is actually result of this thread? AFAICS the PEP still hasn't > > changed. IMO when there's only python3 installed, there should be no > > /usr/bin/python, which also seems to be aligned with what Guido says. > > Would it be possible to update the PEP accordingly? > > Thanks for the prompt. I just pushed an update [1,2] to merge the > previously incorrect bullet point with the one following it, so it now > reads: > > * The more general ``python`` command should be installed whenever > any version of Python 2 is installed and should invoke the same version of > Python as the ``python2`` command (however, note that some distributions > have already chosen to have ``python`` implement the ``python3`` > command; see the `Rationale`_ and `Migration Notes`_ below). Exactly what I was looking for, thanks a lot! > I also pushed a few tweaks to account for the extension of Python 2.7 > maintenance, and to change the verb tense to reflect the fact this was > implemented ages ago [3]. > > Cheers, > Nick. > > [1] https://hg.python.org/peps/rev/3d16b0cd10bc > [2] https://hg.python.org/peps/rev/32b6619e9259 > [3] https://hg.python.org/peps/rev/0418f146b50f > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > -- Regards, Slavek Kabrda ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hi, I am new to this board and have a question
- Original Message - > Hi Everyone, > I am a core software engineer at Rocket Software Inc. I am working on > database system called UniData and Universe. > Now we plan to introduce Python as the new programming language to our > customer. When I try to build the python 3.4.1 on Red Hat Linux platform. I > found some problem and need help. > After I run configure and make the python, at the very end, it said some > optional modules we missing, > Python build finished successfully! > The necessary bits to build these optional modules were not found: > _bz2 _lzma _ssl > _tkinter zlib > So, I went to python development guide site and found out I have to download > some other source to build the optional modules. > Since I am on RH Linux and yum is installed on my Linux box, so I run > following command > # yum install yum-utils > Loaded plugins: product-id, refresh-packagekit, security, > subscription-manager > This system is not registered to Red Hat Subscription Management. You can use > subscription-manager to register. > WANdisco | 951 B 00:00 > WANdisco/primary | 94 kB 00:00 > WANdisco 450/450 > my_repo | 3.9 kB 00:00 ... > Setting up Install Process > Package yum-utils-1.1.30-14.el6.noarch already installed and latest version > Nothing to do > Looks like yum-utils is already installed. Then > # yum-builddep python3 > Loaded plugins: product-id, refresh-packagekit > No such package(s): python3 > So what package name should I gave to download the additional source to build > the optional module? > Thanks! > Jianhua Zhou > > Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ > +1 800.966.3270 ■ +1 781.577.4321 > Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com > Manage Your Subscription Preferences - > http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html > Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy > > This communication and any attachments may contain confidential information > of Rocket Software, Inc. All unauthorized use, disclosure or distribution is > prohibited. If you are not the intended recipient, please notify Rocket > Software immediately and destroy all copies of this communication. Thank > you. Hi Jianhua, this is probably not a question to be asked on this list. If you need some help, please drop me a private mail and I can help you sort this out (I'm the RHEL Python maintainer, so I consider myself pretty knowledgeable about these things ;)). Slavek ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 RPM on AIX
- Original Message - > Blaxton writes: > > > I am using the spec file that comes with Python source code which > > downloaded from python.org website > > Ah, sorry, I didn't realize that. My advice still stands; while there > are Red Hat/Fedora/other-RPM-based distro workers here, I don't know > if any of them actually have anything to do with RPM-building. And > I've been following this list for over 10 years -- this is the first > I've heard of problems with the .spec in the Python sources, so I > suspect Zach is right: you're the first person to use the thing in > half a decade. The Python project itself doesn't distribute RPMs as > far as I can see. Yes, there are people here who do everything around distro RPM-building here :) AFAIK no RPM based distribution uses the specfile from the Python tarball. Our specfiles (Fedora/Red Hat Enterprise Linux) are much more complex to satisfy all the downstream policies and such. In case you're interested, you can have a look at our current python3.spec [1]. Feel free to reuse it (all Fedora specfiles are licensed under MIT license unless noted otherwise). > > This is like no support. > > Unfortunately, yes. I know I don't have the knowledge to help fix the > .spec file, and I don't even know who to tell you to ask in the project. I can help with RPM related questions (it'd probably be best to ask them privately, since their offtopic for this list), but I have pretty much zero knowledge of AIX - so I won't be able to help you with AIX-specific issues. -- Regards, Slavek Kabrda [1] http://pkgs.fedoraproject.org/cgit/python3.git/tree/python3.spec ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Purpose of files in $(DESTDIR)$(LIBPL)
Hi, I'd like to ask about the purpose of files in $(DESTDIR)$(LIBPL) [1] - what is the reason to keep them/what are they useful for? I'm currently "taking over" Python packaging in Fedora and I'd like to know if these have some meaning for a distro-packaged Python (Dave Malcolm is not sure about them ;)). Thanks, Slavek. -- Regards, Bohuslav "Slavek" Kabrda. [1] http://hg.python.org/cpython/file/3.3/Makefile.pre.in#l1206 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3 as a Default in Linux Distros
Hi all,
in recent days, there has been a discussion on fedora-devel (see thread [1])
about moving to Python 3 as a default.
I'd really love to hear opinions on the matter from the upstream, mainly
regarding these two points (that are not that clearly defined in my original
proposal and have been formed during the discussion):
- Should we point /usr/bin/python to Python 3 when we make the move?
I know that pep 394 [2] deals with this and it says that /usr/bin/python may
refer to Python 3 on some bleeding edge distributions - supposedly, this was
added to the pep because of what Arch Linux did, not the other way round.
As the pep says, the recommendation of pointing /usr/bin/python to Python 2 may
be changed after the Python 3 ecosystem is sufficiently mature. I'm wondering
if there are any more specific criteria - list of big projects migrated/ported
or something like that - or will this be judged by what I'd call "overall
spirit" in Python community (I hope you know what I mean by this)?
In Fedora, we have two concerns that clash in this decision - being "First"
(e.g. actively promote and use new technologies and also suggest them to our
users) vs. not breaking user expectations. So we figured it'd be a good idea to
ask upstream to get more opinions on this.
- What should user get after using "yum install python"?
There are basically few ways of coping with this:
1) Just keep doing what we do, eventually far in the future drop "python"
package and never provide it again (= go on only with python3/python4/... while
having "yum install python" do nothing).
2) Do what is in 1), but when "python" is dropped, use virtual provide (*)
"python" for python3 package, so that "yum install python" installs python3.
3), 4) Rename python to python2 and {don't add, add} virtual provide "python"
in the same way that is in 1), 2)
5) Rename python to python2 and python3 to python at one point. This makes
sense to me from the traditional "one version in distro + possibly compat
package shipping the old" approach in Linux, but some say that Python 2 and
Python 3 are just different languages [3] and this should never be done.
All of the approaches have their pros and cons, but generally it is all about
what user should get when he tries to install python - either nothing or
python2 for now and python3 in future - and how we as a distro cope with that
on the technical side (and when we should actually do the switch).
Just as a sidenote, IMO the package that gets installed as "python" (if any)
should point to /usr/bin/python, which makes consider these two points very
closely coupled.
Thank you all for your suggestions and opinions.
Slavek.
--
Regards,
Bohuslav "Slavek" Kabrda.
(*) You can think of a virtual provide as of a "packaging symlink" - adding
"Provides: foo" to package makes "yum install foo" install this package, even
if this package name is "bar".
[1] https://lists.fedoraproject.org/pipermail/devel/2013-July/186098.html
[2] http://www.python.org/dev/peps/pep-0394/
[3] https://lists.fedoraproject.org/pipermail/devel/2013-July/186186.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 as a Default in Linux Distros
- Original Message - > On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote: > > - Should we point /usr/bin/python to Python 3 when we make the move? > > No. > > > - What should user get after using "yum install python"? > > Will a base install include Python 3? If it does, I think yum install > python should mean python3, and hence already be installed. > Yep, base will include Python 3. This is not just about python package, but also all other python extension modules (e.g. python-foo vs. python2-foo vs. python3-foo...). > //Lennart > -- Regards, Bohuslav "Slavek" Kabrda. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 as a Default in Linux Distros
- Original Message -
> Am 24.07.13 11:12, schrieb Bohuslav Kabrda:
> > - Should we point /usr/bin/python to Python 3 when we make the move?
>
> This should depend on the answer to this question:
> - for how long have you been providing /usr/bin/python2 binaries?
>
Huh, I don't know exactly, but quick git blame of our python.spec shows that
/usr/bin/python2 has been there since July 2009, but probably even longer.
> Users "should" have been explicit in declaring scripts as
> /usr/bin/python2 for quite some time now, except that this would break
> on distros which don't provide a python2 symlink.
>
> Ideally, you "should" have warned users to be explicit with python2 if
> the script wouldn't work on python3. But I'd wave this requirement, as
> there is already the upstream PEP.
>
> So (IMO) if it the last three Fedora releases had been providing python2
> binaries, it should be allowed to switch python to be python3. The exact
> number can be debated; it should depend on what releases are still in
> active use so that a script would run on multiple releases.
>
Yep, it seems like 6+ fedora releases and certainly the currently active ones
have that. We will however need to make it clear that everyone, especially
package maintainers, points to /usr/bin/python{2,3}.
> Then you can tell users that possible breakage is easy to fix: just
> install python2, and change the shebang line.
>
> Regards,
> Martin
>
>
--
Regards,
Bohuslav "Slavek" Kabrda.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Building against system expat
Hi, I'm trying to build Python 3.2.3 against system expat library, that lies out of the ordinary directory structure (under /opt). I also have an older version of expat library in the system. No matter what shell variables or options I pass to configure and make, pyexpat gets linked against the system expat, which results in errors during tests: pyexpat.cpython-32dmu.so: undefined symbol: XML_SetHashSalt anyone has any idea what to pass to configure/make to link pyexpat with the other expat? Thanks! -- Regards, Bohuslav "Slavek" Kabrda. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Building against system expat
Hi, I'm trying to build Python 3.2.3 against system expat library, that lies out of the ordinary directory structure (under /opt). I also have an older version of expat library in the system. No matter what shell variables or options I pass to configure and make, pyexpat gets linked against the system expat, which results in errors during tests: pyexpat.cpython-32dmu.so: undefined symbol: XML_SetHashSalt anyone has any idea what to pass to configure/make to link pyexpat with the other expat? Thanks! -- Regards, Bohuslav "Slavek" Kabrda. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building against system expat
- Original Message - > On 25.04.2012 15:42, Bohuslav Kabrda wrote: > > Hi, I'm trying to build Python 3.2.3 against system expat library, > > that lies > > out of the ordinary directory structure (under /opt). I also have > > an older > > version of expat library in the system. No matter what shell > > variables or > > options I pass to configure and make, pyexpat gets linked against > > the system > > expat, which results in errors during tests: > > > > pyexpat.cpython-32dmu.so: undefined symbol: XML_SetHashSalt > > > > anyone has any idea what to pass to configure/make to link pyexpat > > with the > > other expat? > > You'll have to upgrade your expat. The XML_SetHashSalt is new in > 2.1.0 and > makes it possible to avoid an algorithmic complexity attack; Python > uses it > in its newest bugfix releases. See for example > <http://bugs.python.org/issue14234>. > > cheers, > Georg > Thanks, actually I found an error in my build script that set the LD_LIBRARY_PATH wrongly, so only the standard .so file was found (that didn't have this symbol), and not the one under /opt. So, my mistake, thanks everyone :) -- Regards, Bohuslav "Slavek" Kabrda. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
