mpare to Tarek Ziade's existing pypi2rpm project?
From a quick look, the main difference appears to be that pyp2rpm
creates a spec file only, while pypi2rpm creates the RPM directly.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
On 05/23/2012 04:30 PM, Bohuslav Kabrda wrote:
> - Original Message -
>> On 23/05/12 08:16, Nick Coghlan wrote:
>>> How does this compare to Tarek Ziade's existing pypi2rpm project?
>>>
>>> From a quick look, the main difference appears to be
/python2.7/site-packages/setuptools/archive_util.py",
line 67, in unpack_archive
driver(filename, extract_dir, progress_filter)
File "/usr/lib/python2.7/site-packages/setuptools/archive_util.py",
line 154, in unpack_zipfile
data = z.read(info.filename)
;s involved in tweaking the templates.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
undefined quirks of the legacy import
implementation), and a successful rebuild of Fedora's Python 3 stack
would go a long way to alleviating that concern. It also means that any
problems you do find can be fixed before the final release.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructur
approach as an
upstream bugfix, especially if you implement it in Fedora first with no
apparent ill-effects for affected applications.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
___
pytho
in package level components that get imported after the path
reversal.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
sn't play nicely
with PyPy's cpyext.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
On 07/31/2012 03:16 PM, Toshio Kuratomi wrote:
> On Fri, Jul 27, 2012 at 12:27:31PM +1000, Nick Coghlan wrote:
>> On 07/27/2012 07:28 AM, David Malcolm wrote:
>>> With my proposed approach, you have to opt-in, your code can say: when I
>>> say "xml", I really
rastructure than Ubuntu
does, so it's a bigger migration challenge. Does anaconda run on Python
3? Does yum?
It's that delta of Python applications that Fedora ships as required
components in the base OS, but Ubuntu does not, that will potentially
cause problems.
Cheers,
Nick.
--
Nick
t of the two
variants ended up being much larger than originally expected. For pure
Python code, Armin Ronacher's "python-modernize" can help flush out
legacy constructs that will fail under Python 3.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Develop
end user perspective, having things mostly compatible with both
2 and 3 should come *before* that symlink gets flipped rather than after.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
___
pytho
are going to be easy to port (especially those
with intricate dependencies on the Python C API or the broken Python 2
text model), but many should fit fairly easily into the common Python
2/3 language subset.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Bri
case basis as it
comes up.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
in an distro patch would not be a popular decision (to say the least).
However, I think it's enough to place a clear upper limit on the number
of runtimes to be supported (where 'x' is the relevant minor version
packaged in the Fedora repos): CPython 2.x, Py
I metadata.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
le to declare
explicit conflicts for the non-pypi items.
> There's some prior work done by other people:
> * http://www.rpm.org/ticket/154
> * http://lists.fedoraproject.org/pipermail/packaging/2008-June/004715.html
> (Despite my having written that email, the hard parts were all d
out the "shared versions for Python virtual
environments" idea, so you can pitch it to the pip and virtualenv
developers, I can certainly do that, but I don't have time to work on
it, or advocate for it myself.
Regards,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineer
ards,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/)
PulpDist Development Lead (http://pulpdist.readthedocs.org)
___
python-devel maili
On 03/05/2013 12:57 PM, Nick Coghlan wrote:
If you want me to flesh out the "shared versions for Python virtual
environments" idea, so you can pitch it to the pip and virtualenv
developers, I can certainly do that, but I don't have time to work on
it, or advocate for it mysel
On 03/05/2013 01:51 PM, Nick Coghlan wrote:
I'll be at PyCon US next week (from the day before the language summit
through to the end of the sprints). I just wanted to see who else will
be around at the conference - it would be good to meet more Fedora
Python folks in person (and catch up
ook specification, etc).
The two parts likely to be of most interest to those on this list:
Development activities:
https://bitbucket.org/ncoghlan/misc/src/default/pep-0426.txt#cl-124
Dependencies:
https://bitbucket.org/ncoghlan/misc/src/default/pep-0426.txt#cl-577
Cheers,
Nick.
--
Nick
want to talk to the Fedora QA folks about Beaker (including the
in-development autotest integration), but that's less relevant to most
of the folks on *this* list :)
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Test Automation Team Lead
ere is that going through pip
instead of invoking setup.py directly lets you override quite a few bad
default behaviours in setuptools, which means *pip* might be an
appropriate choice as our Python build helper tool :)
That would also let us transparently upgrade to any new metabuild hooks
we
;requires", but doesn't discourage version pinning
Used for metapackages (like PyObjC)
May map nicely to software collections
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Test Automation Team Lead
Beaker Development Le
t should be posted to python.org and distutils-sig some
time this week.
Cheers,
Nick.
[1] http://mail.python.org/pipermail/distutils-sig/2013-May/020868.html
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Test Automation Team Lead
Beaker Development Lead (http://beake
tuptools
>= 0.7, although actually releasing that has been delayed due to pip's
current inability to handle that upgrade properly.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Develo
RHEL releases...). Manageable, but glad I'm not finding out about
this when someone files a bug complaining that they can't install a new
Fedora release in Beaker :)
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development,
On 07/19/2013 06:50 PM, Nick Coghlan wrote:
> On 07/19/2013 01:56 PM, Andrew McNabb wrote:
>> On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
>>>
>>> From packaging point of view, this will probably require:
>>> 1) Renaming python package to pyt
ld be enough to prevent serialisation under this scheme.
However, I have my hands full with packaging issues at the moment (see
PEP 426), and then I still want to fix the model for embedding CPython
(see PEP 432). So if it's left to me, there's no way this idea could
become reality b
the Werkzeug and
Jinja2 Python 3 updates: see
http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/ and
http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicode/).
Cheers,
Nick.
- --
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/22/2013 03:25 PM, Toshio Kuratomi wrote:
> On Mon, Jul 22, 2013 at 10:15:31AM +1000, Nick Coghlan wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 07/20/2013 06:11 AM, Toshio Kuratomi wrote:
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/23/2013 12:42 AM, Toshio Kuratomi wrote:
> On Mon, Jul 22, 2013 at 05:15:50PM +1000, Nick Coghlan wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 07/22/2013 03:25 PM, Toshio Kuratomi wrote:
>>
>&g
>> * people don't use python for raw speed of processing. They really just
>> care if it's fast enough. People who write python code would be happy to
>> take speed increases if they were free. But python2 to python3 requires
>> porting code so it comes wi
strange reason, their efforts are mostly focused on "make it
go faster" at the moment :)
I suspect adding component aliases wouldn't qualify as "small",
though, since that's the kind of data model change that has
significant repercussions throughout the UI and
all is that the sdist
may be a filtered version of what's in the source repo. This may
happen if the repo contains additional files that aren't needed to
build and install the distribution. If an archive has a PKG-INFO file
at the root, it's likely an sdist, if it doesn'
herryPy 2 dependency), since they won't be able to migrate to wheel
based installation any time soon.
See discussion at
http://mail.python.org/pipermail/distutils-sig/2013-August/022450.html
for more details.
Cheers,
Nick.
- --
Nick Coghlan
Red Hat Infrastructure Engineering & Develo
in
3.5+ (i.e. copying a system installed pip if available, and only fall
back to using the bundled wheel if there's no system pip). We just
didn't want to make blazing that trail (since it's not officially
supported by pip at this point in time) a precondition for the PEP 45
ically correct, but the major number changes so rarely
that calling Python feature releases minor releases usually confuses
people).
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Te
l as
using RECORD as a guide to what to copy into a fresh venv). If you get
that working, I'd be interested in a Python 3.5 venv and/or ensurepip
patch to do that by default, and only bootstrap from the embedded wheel
if there was no system pip available.
Cheers,
Nick.
--
Nick Coghlan
Red H
So thanks for reading this through and sending your comments.
Looks good to me from an upstream perspective - making it easier to
support other Python runtimes like PyPy and Jython is a nice added bonus.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering &
something.
So, here's a crazy thought: what if, rather than copying the installed
files directly into the virtual environment, we reverse engineered a
wheel archive *dynamically* from the system install and then installed
from that? That would avoid the problems with trying to bypass pip&#
ata 2.0 is based
on the way pkg_resources.parse_version() already behaves:
>>> pkg_resources.parse_version("1.5") < pkg_resources.parse_version("1.5-1") <
>>> pkg_resources.parse_version("1.5-2")
True
Failing that, I think the uninstall/re
nal and we can just use the metadata version field
directly rather than needing to grab the release increment from the RPM
repo. (I think this situation provides a good practical use case for why
it's important to standardise this feature upstream, too).
Cheers,
Nick.
--
Nick Coghlan
Red Hat H
build tag would mean that directly patching the system
pip would affect future virtual environments, but *not* "python -m
ensurepip --upgrade" in existing virtual environments
I think the latter limitation is fine, and more in line with the
direction we're heading upstream (with the &qu
g list
python-...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing l
t;asyncio" module, a new framework for asynchronous I/O
To download Python 3.4.0 visit:
http://www.python.org/download/releases/3.4.0/
==
Direct link to the What's New guide:
http://docs.python.org/3/whatsnew/3.4.html
Cheers,
Nick.
--
Nick Coghlan
Red Hat Host
On 03/17/2014 05:53 PM, Nick Coghlan wrote:
> Direct link to the What's New guide:
> http://docs.python.org/3/whatsnew/3.4.html
Rereading that, I remembered there's more to it for Fedora than just
"hey, here's a shiny new version of Python 3 to be packaged", and I
packages install into
dist-packages instead of site-packages, but I wonder if we could so some
tweaks in site and sysconfig to instead redirect pip to /usr/local.
I'll think about that one a bit more - could be a good thing to hack on
at the PyCon US sprints next month.
Cheers,
Nick.
--
02094
Is anyone able to help nudge that along?
Cheers,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
___
python-devel mailing list
python-devel@lists.fedora
th new features committed yesterday just by doing
> `dnf update`.
I actually mentioned this in my recent SciPy keynote, on the grounds
that scientists may want to play around with the new matrix
multiplication operator without having to build Python from source :)
Cheers,
Nick.
--
Nick Cogh
This is also the part of the PEP most likely to break things, so
figuring out a way to test it in Fedora before it makes it into an
upstream CPython release would be a good idea...
Cheers,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisb
ow. If we break something, we can just revert it quickly and everything will
> be fine.
>
> Is someone strictly against this or shall I move on with patching our rawhide
> Python?
Patching rawhide would be wonderful. The patch is at last passing
Python's own test suite, so
g list - on the other hand, I don't want to look like I'm
> spamming everyone needlessly... What do you think would be the best place to
> announce this? python-announce-list?
You can get away with a lot on python-ideas, and you're likely to find
folks potentially inter
.py{c,o} files being
> created for each rebuild.
This sounds like a reasonable approach to me, especially if the mtime
for the SRPM is derived from dist-git.
Regards,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisionin
On 08/07/2014 06:10 PM, Robert Kuska wrote:
> - Original Message -
>> From: "Nick Coghlan"
>> On 07/30/2014 12:16 AM, Bohuslav Kabrda wrote:
>>> So the question is, are we feeling lucky? :) I'd say yes, since rawhide has
>>> just recently
On 08/18/2014 04:23 PM, Robert Kuska wrote:
>
>
> - Original Message -
>> From: "Nick Coghlan"
>> To: python-devel@lists.fedoraproject.org
>> Sent: Monday, August 18, 2014 7:57:21 AM
>> Subject: Re: Python 2.7 SSL upgrade patch available for t
e can come up with a way to integrate it
nicely with COPR, or even tidy up the implementation to the point where
we can convince Clark to accept the feature as part of mock itself :)
Regards,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
[1].
>
> [1] http://copr.fedoraproject.org/coprs/churchyard/python3-nightly/
Oh, I hadn't even thought of that, but yes, rebuilding for an SCL could
be very cool. The "How do we rebuild/repackage our dependencies?" was
actually one of the problems we ran into when considering us
lready discovered minor
> issue in test_ssl.py [2] while scratch building.
Thanks for that!
Just as an update - the SSL backport patch has been merged into the 2.7
branch upstream, so it will definitely be in 2.7.9.
Regards,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Soft
eed it for Beaker).
Cheers,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
files from the
sdist, then pbr is going to need access to the original git repo in
order to generate them (see
http://docs.openstack.org/developer/pbr/#what-it-does for the things it
can automatically derive).
Regards,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Develo
information out of it" guidance for sys.version.
The version without dots can be addressed by including the leading zero:
"{0.major}{0.minor}{0.micro:02d}".format(sys.version_info)
Cheers,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development,
original 3.0 release.
> so I'll change the definition as you advise, using version_info, just without
> the leading
> zero. :)
Sounds good.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Archit
On 4 Dec 2014 00:38, "Bohuslav Kabrda" wrote:
>
> So here are my proposals for changes in current guidelines [2]:
> - In [3], it says "If the executables provide the same functionality
independent of whether they are run on top of Python 2 or Python 3, then
only one version of the executable shoul
On 4 Dec 2014 00:59, "Donald Stufft" wrote:
>
>
> On Dec 3, 2014, at 9:51 AM, Nick Coghlan wrote:
>
>> > - (This is not really related to the switch, but more of a general
remark) In [4], it says that "python 3 version of the executable gains a
python3- pref
On 4 December 2014 at 23:10, Bohuslav Kabrda wrote:
> - Original Message -
>> On Thu, Dec 04, 2014 at 12:51:40AM +1000, Nick Coghlan wrote:
>> >
>> > On 4 Dec 2014 00:38, "Bohuslav Kabrda" wrote:
>> > > - (This is not really related to th
quot;, even if their dependencies aren't available in
Python 3 yet.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.or
on" macro isn't defined?
That would give people 3 explicit options to choose from:
* always run in Python 2
* always run in Python 3
* run in the same Python as Anaconda and yum
Single source Python 2/3 compatibility could then be made a policy
requirement for packages opting
On 28 January 2015 at 03:32, Toshio Kuratomi wrote:
> On Tue, Jan 27, 2015 at 10:50:07PM +1000, Nick Coghlan wrote:
>> What if, instead, we were able to add a new macro that let folks
>> *explicitly* opt in to running in the "system Python", but then define
>> the r
s with custom scripts)
* hold off on switching the default for the time being and instead
focus on enabling explicitly opting in to Python 3 in EPEL
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-dev
On 5 February 2015 at 17:48, Nick Coghlan wrote:
> On 4 February 2015 at 21:01, Bohuslav Kabrda wrote:
>> - Original Message -
>>> I don't really feel strongly about this, I agree that your solution has a
>>> merit (and syspython *is* better than defau
On 27 February 2015 at 11:02, Toshio Kuratomi wrote:
>
> On Feb 25, 2015 3:14 PM, "Nick Coghlan" wrote:
>
>> For those not following along with the FPC ticket, Toshio and Tomspur
>> have a nice write-up of the options at
>> https://etherpad.mozilla.org
le format will be defined by CPython upstream rather than by the
distro.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
ty of cases.
Such a page could also be linked from
https://packaging.python.org/en/latest/deployment.html#os-packaging-installers,
providing a clearer entry point for Pythonistas already familiar with
Python's packaging tools into the RPM ecosystem.
Cheers,
Nick.
--
Nick Coghlan | ncogh
On 11 June 2015 at 14:05, Jason L Tibbitts III wrote:
>>>>>> "NC" == Nick Coghlan writes:
>
> NC> I agree it doesn't make sense to include that information in the
> NC> Python packaging guidelines, but I think it does make sense to
> NC> pro
On 11 June 2015 at 14:38, Nick Coghlan wrote:
> My own packaging experience is limited enough that I don't consider
Heh, that's specifically *Fedora* packaging experience. Software
packaging and distribution in general is a very different story :)
Cheers,
Nick.
--
Nick Coghla
plausible approach, I'd volunteer to
work with Matej as Python 3 maintainer to push it forward.
Regards,
Nick.
P.S. Miro's nightly SCLs at
https://copr.fedoraproject.org/coprs/churchyard/python3-nightly/ may
also have a part to play, although I'm not sure what that would be
just ye
On 18 Jun 2015 10:02 pm, "Matej Stuchlik" wrote:
> We feel that that's perhaps a little tight schedule, where things could
> go wrong easily. For that reason we'd like stay with Python 3.4 as system
> python for Fedora 23, while providing Python 3.5 in a Copr. (Perhaps using
> Miro's repo)
>
> Doe
On 14 July 2015 at 21:19, Miro Hrončok wrote:
> I would like to thank all the contributors, who are helping us with
> this. We are working on a special Fedora Badge for this Python 3 effort [4].
Thanks for the update, and I love the badge idea!
Cheers,
Nick.
--
Nick Coghlan |
uld run their *own* scripts in a different Python
interpreter by default (e.g. an SCL, or PyPy), without having to touch
the default Python at the system level (i.e. when running Python
scripts as root).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Austral
the "Python 3 as default"
change, but didn't see anything.
Was there something there and I just missed it, or does something need
to be written up and passed to the folks responsible for creating the
release notes?
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Bris
to this:
* Reporting on proposal status as a standard thing in Alpha release
notes: https://bugzilla.redhat.com/show_bug.cgi?id=1258093
* Providing inline instructions for updating Alpha/Beta release notes:
https://bugzilla.redhat.com/show_bug.cgi?id=1258094
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
h the upstream metadata
generation?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
On 23 September 2015 at 02:54, Jason L Tibbitts III wrote:
>>>>>> "NC" == Nick Coghlan writes:
>
> NC> I just noticed that the packaging policy doesn't currently mention
> NC> dist-info directories, only the older egg-info:
> NC> https://fe
/SoftwareComponentPipeline#Individual_language_SIG_responsibilities
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
that install the distro's Django package?
If so, then there's some relevant work currently under way upstream to
improve the interaction between Python installation tools and build
systems to improve the metadata extraction process, rather than
relying on implementation details of s
On 17 November 2015 at 22:05, Neal Gompa wrote:
> On Tue, Nov 17, 2015 at 3:26 AM, Nick Coghlan wrote:
>> I'm not clear on what you mean by depending on an egg. Eggs are a
>> binary format that isn't compatible with Linux distro packaging
>> policies, sinc
2 spec [1]
While dropping the suffix entirely seems like a potentially attractive
option to me, it may also be ambiguous as to whether it's referring to
import package names (eg. "python2(pkg_resources)") or distribution
package names (e.g. "python2(setuptools)").
Cheers,
On 18 November 2015 at 02:29, Jason L Tibbitts III wrote:
>>>>>> "NC" == Nick Coghlan writes:
>
> NC> If so, then there's some relevant work currently under way upstream
> NC> to improve the interaction between Python installation tools and
> N
or those who want pythonXdist() Provides, but it is
> opt-in rather than opt-out. The option is only for distributions that
> intend to carry only one Python runtime per major version.
Very cool, thank you!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
does to either:
* carry the Python 3 support as a downstream patch; or
* expose the upstream complexity to downstream users
As Toshio notes, it's also possible that if the pdfminer.six fork sees
sufficient interest, the original pdfminer maintainer may reconsider
their willingness to accep
the parallel install model
adopting for the python3X releases in EPEL means there's a chance to
rebase the "default" version of other packages each time "X" is
incremented. While that won't be a big difference for the python34 and
python35 stacks, there
also
https://github.com/developer-portal/content/issues/61 which proposes
tweaking https://developer.fedoraproject.org/deployment/rpm/about.html
to provide pointers to language specific tools.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
lowing variables defined
> LANG=en_GB.utf8
> LC_ALL=en_GB.utf8?
>
> Python3 uses locale.getpreferredencoding when no encoding is specified
> when opening
> a file which may be an ascii on some systems.
>
Fedora 24 will be shipping with
On 23 February 2016 at 13:13, Toshio Kuratomi wrote:
> On Feb 22, 2016 6:15 PM, "Nick Coghlan" wrote:
> > Fedora 24 will be shipping with a C.UTF-8 locale:
> https://bugzilla.redhat.com/show_bug.cgi?id=902094
> >
> > Perhaps we should file an RFE with rpm and
would tip the answer towards "Yes" :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
ance
> team, and I'm generally interested Python in Fedora. Please let me in? :)
And here I'd been assuming you were already a member - welcome! :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
m() will fail noisily in those cases, so
you can either switch to the random module, or fix your entropy pool
seeding".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
On 8 August 2016 at 13:10, Nick Coghlan wrote:
> Accordingly, what I propose we do is as follows:
>
> 1. Raise the concern in the F26 system-wide change proposal for migrating
> to Python 3.6
> 2. Apply the patch when the 3.6 beta releases are added to Fedora Rawhide
> 3. Dec
1 - 100 of 195 matches
Mail list logo
