On Sun, 13 Jan 2019 at 19:36, Miro Hrončok wrote:
> On 13. 01. 19 7:57, Nick Coghlan wrote:
> > Anyway, Zbigniew has resubmitted the change to make the package policy
> > compliant as a new PR:
> > https://src.fedoraproject.org/rpms/catfish/pull-request/2
>
> This is a
olicy
compliant as a new PR:
https://src.fedoraproject.org/rpms/catfish/pull-request/2
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscrib
-...@python.org/message/TYENF32X7E6U3M2WJWMTH5DTJEXZBVMS/
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le
of Łukasz's proposal was that if a significant
regression *was* found in a point release, then the resolution would be to
spin a new point release with a fix ASAP. It's just that in such cases, the
version numbers involved would be X.Y.Z and X.Y.Z+1 rather than X.Y.Zrc1
and X.Y.Z.
Cheers,
Nick.
--
Nick C
> which would be the recommended way to make `python` invoke Python 3.
Cool, thanks for moving this forward!
Did you want to update
https://fedora-python.readthedocs.io/en/latest/plans/default-python-module/
accordingly, or should that entire site just be scrubbed as an
experimental idea that didn'
setup.
Cheers,
Nick.
P.S. Using a dedicated environment variable would have the advantage
of allowing anyone else that *also* wanted to look for and remove
unqualified references to Python 2 to set it.
--
Nick Coghlan | ncogh...@gmail.com | Bris
PR to fix that:
https://github.com/python/cpython/pull/4565
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to pytho
On 18 November 2017 at 06:54, Toshio Kuratomi <a.bad...@gmail.com> wrote:
> On Thu, Nov 16, 2017 at 8:43 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> Switching to a wheel based build doesn't change either the starting
>> point (which is still an sdist) or th
On 17 November 2017 at 11:55, Toshio Kuratomi <a.bad...@gmail.com> wrote:
>
> On Thu, Nov 16, 2017 at 5:37 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > So the two possible approaches are:
> >
> > * traditional sdist: "setup.py build", "setu
atter page is mainly in GitHub because I couldn't figure out how
to get Pagure's RTD integration to work, but I also see some benefits in
lowering barriers to contribution for Python folks that already have GitHub
accounts, but don't have Fedora accounts yet.
--
Nick Coghlan | ncog
named
https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file -
that is the setup.py based build process, but it isn't currently obvious
that `pyX_build` and `pyX_install` assume the use of a setup.py file.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Austr
On 16 November 2017 at 16:51, Elliott Sales de Andrade <
quantum.anal...@gmail.com> wrote:
> On 16 November 2017 at 01:31, Nick Coghlan <ncogh...@gmail.com> wrote:
>>
>> However, if flit is now adding its own shim implcitly, then the answer
>> would just
hat directly.
If that's still the case, then the answer would be "Yes, but only if you
make sure the sdist still contains a suitable setup.py shim".
However, if flit is now adding its own shim implcitly, then the answer
would just be "Yes".
Cheers,
Nick.
--
Nick
0
or Beta Target 1
* Final Target 2: fallback release target if Beta Target 1 and/or Final
Target 1 are missed
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
On 31 August 2017 at 22:09, Matthew Miller <mat...@fedoraproject.org> wrote:
> On Thu, Aug 31, 2017 at 08:11:56PM +1000, Nick Coghlan wrote:
>> > I'd think the solution is simply to mark your module with "Service
>> > Level: alpha" (and then we'd want some to
On 30 August 2017 at 21:56, Matthew Miller <mat...@fedoraproject.org> wrote:
> On Wed, Aug 30, 2017 at 07:43:21PM +1000, Nick Coghlan wrote:
>> As a concrete example, the upstream Python 3.7 alpha & beta cycle will
>> be running in parallel with the F28 development cycle.
o
do things like "tags: [f26, f27]" (for example) to indicate that a
stream was the default in particular versions of Fedora.
For ease of adoption of stream expansion, there could also be a notion
of making "active" an implied tag for any non-EOL stream, such that
you'd have to opt-o
On 29 August 2017 at 19:33, Petr Viktorin <pvikt...@redhat.com> wrote:
> On 08/25/2017 10:23 AM, Nick Coghlan wrote:
>> Traditionally, that would have meant that we wouldn't get a Fedora
>> based Python 3.7 container out the door until the release of Fedora 29
>> in O
On 24 August 2017 at 21:28, Petr Viktorin <pvikt...@redhat.com> wrote:
> On 08/24/2017 12:22 PM, Nick Coghlan wrote:
>>> Stream names match the Platform module. We follow its policy here, even
>>> when
>>> it changes.
>>
>> Oh, interesting, I had tha
On 24 August 2017 at 19:02, Petr Viktorin <pvikt...@redhat.com> wrote:
> On 08/24/2017 10:13 AM, Nick Coghlan wrote:
>> My current thinking based on that discussion is that we're actually
>> going to need a module set that looks like this for F28+:
>>
>> * Platfor
On 21 August 2017 at 19:46, Petr Viktorin <pvikt...@redhat.com> wrote:
> On 08/18/2017 01:38 PM, Nick Coghlan wrote:
>> Does that approach sound sufficiently plausible to folks that I can
>> use it to provide feedback to the folks working on the modularity
>> toolin
On 21 August 2017 at 19:53, Petr Viktorin <pvikt...@redhat.com> wrote:
> On 08/18/2017 12:06 PM, Nick Coghlan wrote:
>> I couldn't get Pagure's webhooks to work properly (see
>> https://pagure.io/pagure/issue/2522), so revising the revised plan:
>> could someone with th
ainer would *prevent* you from
including any regular userspace Python components - you'd only be able
to include the ones built specifically for that stream.
Does that approach sound sufficiently plausible to folks that I can
use it to provide feedback to the folks working on the modularity
tooling
On 15 August 2017 at 19:44, Nick Coghlan <ncogh...@gmail.com> wrote:
> So I decided to set up a build on ReadTheDocs instead, and that looks
> to have just worked, including the logo rendering:
> https://fedora-python.readthedocs.io/en/latest/
I couldn't get Pagure's webhooks t
On 11 August 2017 at 17:34, Nick Coghlan <ncogh...@gmail.com> wrote:
> The relocated "default Python module" proposal is at
> https://docs.pagure.org/fedora-python.fedora-python/default-python-module.html
>
> I'm not super fond of that auto-generated URL, nor do I lik
On 2 August 2017 at 21:34, Nick Coghlan <ncogh...@gmail.com> wrote:
> While working on
> https://fedoraproject.org/wiki/User:Ncoghlan/Default_python_module, I
> started getting annoyed at the lack of decent review and commenting
> features in MediaWiki, so prompted by
> ht
es
4. Categorise as an application if neither 2 nor 3 apply
If it works in practice, such an approach would also help pick up
cases like libvirt-python, where a Py3 RPM exists, but isn't called
"python3-".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
les?
3. Would we allow daisy chaining of these private venvs via *.pth
files? (see https://github.com/berdario/pew#add)
4. How would we make this manageable across Fedora/EPEL/SCLo spec files?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python
2, always runs Python 3).
For that to be supportable, we need *distro* packages to always
specify either python2 or python3 (otherwise they'll break in the "not
specified" configuration, or when the alias points to the "wrong"
version).
Cheers,
Nick.
--
Nick Coghla
to the question of "compatibility of both /bin/sh *and* the
default contents of PATH" than it is pure syntactic compatibility, but
the six compatibility library provides most of the necessary pieces.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australi
ovides can disappear along with it. If it turns out that a future
Python 4.0 is judged to be a drop-in replacement for the last Python
3.x release, then that will be a nice problem to have, and presumably
one we'll have the appropriate tools to handle.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
On 31 July 2017 at 05:19, Björn Persson <Bjorn@rombobjörn.se> wrote:
> Mathieu Bridon <boche...@daitauha.fr> wrote:
>> On Mon, 2017-07-31 at 00:02 +1000, Nick Coghlan wrote:
>> > So that's effectively a hard design constraint for me: folks
>> > targeting
ch that "/usr/bin/python" is taken to mean "written
in the oldest Python dialect that is still actively supported by
upstream and/or commercial vendors (or potentially even older than
that)" while "/usr/bin/python3" retains its current meaning of "run in
the default Pytho
initions available to older EL releases).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
initions available to older EL releases).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
7 Modular Server should look
like yet, let alone a "default-python" module that controls what
"/usr/bin/python" refers to. However, it seems to me that an approach
like that *should* work, so it's an idea I'm going to pursue until we
either having a working "Change it back!"
uch that the error also
suggests directly how to fix it), and there are various other things
we can consider to help smooth the transition (like providing the
"six" and "future" compatibility modules by default in both our Python
2 and Python 3 stacks in order to make portab
any currently unqualified
description and files sections
A script like that may even do a tolerable job for packages that *do*
offer Python 3 subpackages (since those will already have qualifiers,
and will necessarily appear after any unqualified runtime and build
requirements for the
any currently unqualified
description and files sections
A script like that may even do a tolerable job for packages that *do*
offer Python 3 subpackages (since those will already have qualifiers,
and will necessarily appear after any unqualified runtime and build
requirements for the
On 20 July 2017 at 16:12, Bohuslav Kabrda <bkab...@redhat.com> wrote:
> On Thu, Jul 20, 2017 at 7:51 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> * checking for refleaks means we can't run parallel tests across
>> multiple processes. If we were to move refleak testi
ator of
where to focus efforts if the goal is to make the tests more
efficient.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe se
n has a long history in the standards
world (including language standards like C89 and C++11)
In that context, a stream label like "cy2017" would just mean "initial
version set defined in calendar year 2017", while "cm201706" (for
"calendar month") would allo
On 3 July 2017 at 02:04, Stephen John Smoogen <smo...@gmail.com> wrote:
> On 1 July 2017 at 21:42, Nick Coghlan <ncogh...@gmail.com> wrote:
>> On 1 July 2017 at 03:36, Adam Williamson <adamw...@fedoraproject.org> wrote:
>>> On Fri, 2017-06-30 at 12:07 +1000, Ni
On 1 July 2017 at 03:36, Adam Williamson <adamw...@fedoraproject.org> wrote:
> On Fri, 2017-06-30 at 12:07 +1000, Nick Coghlan wrote:
>> Even if a 4.0 does happen, the magnitude of the change relative to the
>> preceding 3.x release is expected to be comparable to that bet
So the currently proposed timeline for an unqualified "python-foo"
switching to meaning "python3-foo" is around the time where upstream
community support for Python 2.x ends.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
prefix and %py3_prefix), and either
leave the latter undefined for systems with no native Py3 stack, or
else set it to rely on EPEL, IUS, or a suitable software collection.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
prefix and %py3_prefix), and either
leave the latter undefined for systems with no native Py3 stack, or
else set it to rely on EPEL, IUS, or a suitable software collection.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 22 June 2017 at 12:54, Neal Gompa <ngomp...@gmail.com> wrote:
> On Wed, Jun 21, 2017 at 10:25 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> 1. How to modify a package to explicitly declare it as "Python 2 only"
>> (and the need for a "BuildRequires:
, just with more explicit guidance on how to handle that
request in a relatively easy to maintain way :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
it that give
maintainers more specific directions regarding what they need to do,
rather than requiring them to figure out the necessary changes for
themselves by reading through the updated packaging policy and then
comparing it to their current spec f
s at least arguably the most future-proof way to design a
spec file (and definitely the easiest variant to keep consistent
across OS versions at a spec file level).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 20 June 2017 at 12:44, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 20 June 2017 at 02:49, Przemek Klosowski <przemek.klosow...@nist.gov>
> wrote:
>> It seems to me that there are two kinds of Python packages affected by this
>> issue: some track the evolution
s that have been
keeping up with their Python 3 compatibility checking only need to
change one thing (i.e. switching their build dependency to Python 3
rather than Python 2), rather than everything. The only folks that
would need to make sweeping changes to their dependency declarations
are
On 2 June 2017 at 18:46, Nick Coghlan <ncogh...@redhat.com> wrote:
> On Fri, Jun 2, 2017 at 1:15 PM, Zbigniew Jędrzejewski-Szmek
> <zbys...@in.waw.pl> wrote:
>> It seems that right solution, that would work while the builders are
>> still not F26, would be to con
ently change LC_CTYPE to the more
sensible setting.
The accepted version of the PEP upstream *only* sets LC_CTYPE, so the
chance of unintended side effects from the coercion is much lower that
it was with the approach that made the F26 Beta cut-off (which also
sets LANG).
Cheers,
Nick.
--
Nick Cog
any paths that would
later prove to be an absolute deal-breaker for updating the distro
level recommendations.
Cheers,
Nick.
[1] https://github.com/leapp-to/prototype/issues/126
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
pyt
On 2 May 2017 at 09:36, Nico Kadel-Garcia <nka...@gmail.com> wrote:
> On Mon, May 1, 2017 at 9:14 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> On 1 May 2017 at 22:47, Nico Kadel-Garcia <nka...@gmail.com> wrote:
>>> On Sun, Apr 30, 2017 at 10:30 PM, Nic
nstall directory to /usr/local in a way that "pipsi" detects)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
On 1 May 2017 at 22:47, Nico Kadel-Garcia <nka...@gmail.com> wrote:
> On Sun, Apr 30, 2017 at 10:30 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> If the intended benefit of this change remains unclear, it may help to
>> focus on a specific concrete case, which
On 1 May 2017 at 22:47, Nico Kadel-Garcia <nka...@gmail.com> wrote:
> On Sun, Apr 30, 2017 at 10:30 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> If the intended benefit of this change remains unclear, it may help to
>> focus on a specific concrete case, which
the installed-via-pip versions easier to
identify even without checking the PEP 376 installation metadata)
Cheers,
Nick.
[1]
https://www.slideshare.net/ncoghlan_dev/developing-in-python-on-red-hat-platforms-devnation-2016
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
the installed-via-pip versions easier to
identify even without checking the PEP 376 installation metadata)
Cheers,
Nick.
[1]
https://www.slideshare.net/ncoghlan_dev/developing-in-python-on-red-hat-platforms-devnation-2016
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
ing the PEP 376 metadata.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
On 28 April 2017 at 00:07, Stephen John Smoogen <smo...@gmail.com> wrote:
> On 27 April 2017 at 02:32, Nick Coghlan <ncogh...@gmail.com> wrote:
>> At this moment, this is NOT true for Fedora and derivatives. Instead,
>> the remediation step here is "sudo pip unin
On 27 April 2017 at 23:04, Daniel P. Berrange <berra...@redhat.com> wrote:
> On Thu, Apr 27, 2017 at 04:32:09PM +1000, Nick Coghlan wrote:
>> Their approach means that any harm caused by "sudo pip install X" can
>> subsequently be fully reversed
On 27 April 2017 at 23:04, Daniel P. Berrange <berra...@redhat.com> wrote:
> On Thu, Apr 27, 2017 at 04:32:09PM +1000, Nick Coghlan wrote:
>> Their approach means that any harm caused by "sudo pip install X" can
>> subsequently be fully reversed
we are in terms of
existing container and system package build processes, but also have
to provide sensible behaviour on non-Linux systems (see [1] for the
gory details).
Cheers,
Nick.
[1] https://github.com/pypa/pip/issues/1668
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
d a "sudo
make install" from the main Python development branch will mess with
the default symlinks if you didn't set a suitable `/opt/` prefix).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -
ip`, and the venv module is patched to
convert the system level pip back into a wheel archive, which it then
installs into the created virtual environments.
It's definitely not pretty, but it works.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
> /usr/lib. Because the components are modular and bundled in a non-RPM
> compatible fashion, it behooves developers to use a tool to segregate
> the tools as much as feasible from the Fedora underlying
> infrastructure. i.e., use pyvenv to build them in a contained
> environme
> /usr/lib. Because the components are modular and bundled in a non-RPM
> compatible fashion, it behooves developers to use a tool to segregate
> the tools as much as feasible from the Fedora underlying
> infrastructure. i.e., use pyvenv to build them in a contained
> environment
delegation today:
https://mail.python.org/pipermail/python-dev/2017-April/147796.html
So with any luck, we should be able to get this change explicitly
approved by upstream within the next couple of weeks.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
rovements to packaging collaboration across the RPM-based distros are
always going to get a big thumbs up from me :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.f
at to
me, and I see from https://fedoraproject.org/wiki/Category:ChangeAnnounced
that it's already been announced on fedora-devel.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fe
in most cases it's not what they
> should be doing (`pip install --user` is usually more appropriate).
>
> What do you think?
I guess when you're building an RPM you're not typically running as
root either, so standard RPM builds would still be fine. So +1 from
me.
Cheers,
Nick.
--
Nick Coghl
th '--upgrade' option.
This, on the other hand, is why having the system site-packages
visible is discouraged in general - it really is more complicated than
using an environment that only shares that standard library and the
language runtime.
Cheers,
Nick.
--
Nick Coghlan | nc
On 8 February 2017 at 13:44, Tadej Janež <tade...@nez.si> wrote:
> Nick,
>
> thanks for your thorough answer.
>
> On Mon, 2017-02-06 at 20:07 +0100, Nick Coghlan wrote:
>>
>> It's not specific to Fedora's Python 3 packaging as such, but it *is*
>> specific t
ner image atop a RHEL or
CentOS container host rather than running directly on the host.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
ady has to
getentropy.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
On 24 December 2016 at 02:38, John Dulaney <jdula...@fedoraproject.org>
wrote:
> On Fri, Dec 23, 2016 at 05:37:51PM +1000, Nick Coghlan wrote:
>
> > I filed that idea on the pip issue tracker at
> > https://github.com/pypa/pip/issues/4197 but figured I should rai
/4197 but figured I should raise it here
as well, as if something like this was added, then Fedora could be updated
to use a standard symlink map when building RPMs, and the developer portal
could be updated with suggest `pip.conf` settings to use the system cert
bundle by default.
Cheers,
Nick.
-
m suggesting "Some libraries,
applications and operating system interfaces may not work correctly."
as that's literally the answer to "Why isn't the C locale allowed by
default anymore?".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
an Python 3, so Armin did make some initial
attempts to get it working in the C locale on both 2 & 3. However, he
eventually gave the latter up as unsupportable and the error makes it
clear that "I don't need to support ASCII based locales on Python 3"
is a key
On 15 December 2016 at 21:17, Toshio Kuratomi <a.bad...@gmail.com> wrote:
> On Mon, Dec 12, 2016 at 1:39 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> I don't anticipate any major concerns with downstream redistributors
>> adding this behaviour, as the main thing
On 12 December 2016 at 20:37, Petr Viktorin <pvikt...@redhat.com> wrote:
> On 12/10/2016 02:56 PM, Nick Coghlan wrote:
>> I also have an upstream motive for suggesting this, though: if we do
>> this in the more constrained environment of "Fedora users" an
blindly upgrading everything
in --user can easily break previously working setups.
So if we wanted to offer this, it would likely need to be as a
standalone (pip installable?) script that was equivalent to the above
bash snippet.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | B
On 12 December 2016 at 19:59, Tomas Orsava <tors...@redhat.com> wrote:
> On 12/12/2016 05:39 AM, Nick Coghlan wrote:
>> On 11 December 2016 at 01:33, Donald Stufft <don...@stufft.io> wrote:
>> The benefit of that approach is that it would not only solve the
>
TF-8", 1);
}
(Plus error checking and the warning on stderr that this was being done)
I guess the next step would be for me to try this in a local clone,
and see what happens when running "LANG=C ./python -m regrtest" as
well as when running click.
Cheers,
Nick.
en make sense to start using the "Local version identifier" feature
in PEP 440 to expose RPM release numbers to Python level tooling:
https://www.python.org/dev/peps/pep-0440/#local-version-identifiers
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
ndencies (e.g. requirements.txt) are
intended for deployment rather than redistribution, and hence can (and
usually should) pin the exact combination of dependencies that was
tested.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
ndencies (e.g. requirements.txt) are
intended for deployment rather than redistribution, and hence can (and
usually should) pin the exact combination of dependencies that was
tested.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 4 November 2016 at 02:16, Charalampos Stratakis <cstra...@redhat.com> wrote:
> And FESCo ticket about that[0]
>
> [0] https://pagure.io/fesco/issue/1642
Awesome, thanks for tackling this.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Bris
On 18 October 2016 at 00:49, Charalampos Stratakis <cstra...@redhat.com> wrote:
> The current URL should be https://beaker.qa.fedoraproject.org/ if that is the
> one you have in mind.
Indeed it is, thank you!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisban
run that on the Red Hat internal instance instead)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
in early December.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
" to *just work*, and give you an
environment for testing software compatibility against multiple
versions of Python from 2.6 through to 3.5+.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
l dependency flow between Fedora and RHEL/CentOS).
However, I'm also a strong +1 for making tox work well by default in
Fedora, and that means providing widely used Python runtime versions,
even if they're officially EOL upstream and now only supported by
redistributors.
Cheers,
Nick.
--
Nick
On 3 October 2016 at 23:36, Tomas Orsava <tors...@redhat.com> wrote:
> On 09/27/2016 08:43 AM, Nick Coghlan wrote:
>>>
>>> P.P.S. I realize rh-python34 is available on RHSCL, but it didn't seem to
>>> support "python3" in scripts...
>&g
e contributed
> to the package's git.
+1 that sounds like an excellent idea :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lis
ys.path, and then defining a custom path_hook to process it:
https://docs.python.org/3/reference/import.html#path-entry-finders
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-
1 - 100 of 178 matches
Mail list logo
