etup.
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 | Brisbane, Australia
___
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 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 tooling where SL-alpha
On 30 August 2017 at 21:56, Matthew Miller 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. It would be
>> beneficial
e you'd be able to
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 n
n3.6 lib directories
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
uns 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 Cog
that's
closer 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, Au
hon3
SRPM) pointed it at python3.
Cheers,
Nick.
P.S. After talking to Petr Viktorin about it off-list, I *don't* think
we should do anything similar for the unqualified "python-foo" RPM
dependencies - once the Python 2.7 stack goes away, those unqualified
provides can disappear alon
On 31 July 2017 at 05:19, Björn Persson wrote:
> Mathieu Bridon 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 EL6 and EL7 *are* going to have to use "/usr/bi
of the unqualified variant to
shift slightly such 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 i
age maintainers and increases the opportunity
> for errors.
Aye, I agree we should be actively seeking to make single-spec
feasible across Fedora/RHEL/CentOS, at least in combination with EPEL
(without the EPEL dependency, it's hard to consistently make new
Fedora level macro definitions avai
odular 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 "C
such 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 t
alified
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
finition 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"
On 3 July 2017 at 02:04, Stephen John Smoogen wrote:
> On 1 July 2017 at 21:42, Nick Coghlan wrote:
>> On 1 July 2017 at 03:36, Adam Williamson wrote:
>>> On Fri, 2017-06-30 at 12:07 +1000, Nick Coghlan wrote:
>>>> Even if a 4.0 does happen, the magnitude
On 1 July 2017 at 03:36, Adam Williamson 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 between any
>> given 3.x and
3 (and
that's what the migration strategy proposed in
https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3
accomplishes).
Keep in mind that if we translate the target releases on the wiki page
to calendar dates:
* Fedora 30 ~= first half of 2019
* Fedora 32 ~= first half of 2
_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
On 22 June 2017 at 12:54, Neal Gompa wrote:
> On Wed, Jun 21, 2017 at 10:25 PM, Nick Coghlan wrote:
>> 1. How to modify a package to explicitly declare it as "Python 2 only"
>> (and the need for a "BuildRequires: epel-rpm-macros" to reliably get
>> ac
proposed, 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
ound 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 files.
Cheers,
Nick.
--
Nick Coghlan |
it's not allowed, even
though it'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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
On 20 June 2017 at 12:44, Nick Coghlan wrote:
> On 20 June 2017 at 02:49, Przemek Klosowski
> wrote:
>> It seems to me that there are two kinds of Python packages affected by this
>> issue: some track the evolution of the ecosystem and make sure they work
>> with both P
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 those whose
On 2 May 2017 at 09:36, Nico Kadel-Garcia wrote:
> On Mon, May 1, 2017 at 9:14 AM, Nick Coghlan wrote:
>> On 1 May 2017 at 22:47, Nico Kadel-Garcia wrote:
>>> On Sun, Apr 30, 2017 at 10:30 PM, Nick Coghlan wrote:
>>>> If the intended benefit of this change r
On 1 May 2017 at 22:47, Nico Kadel-Garcia wrote:
> On Sun, Apr 30, 2017 at 10:30 PM, Nick Coghlan wrote:
>> If the intended benefit of this change remains unclear, it may help to
>> focus on a specific concrete case, which would be that the following
>> operations
ocal/ split helps
there as well, by making 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
On 28 April 2017 at 00:07, Stephen John Smoogen wrote:
> On 27 April 2017 at 02:32, Nick Coghlan wrote:
>> At this moment, this is NOT true for Fedora and derivatives. Instead,
>> the remediation step here is "sudo pip uninstall X && sudo dnf
>> reinstall "
On 27 April 2017 at 23:04, Daniel P. Berrange 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 by doing "sudo pip uninstall X".
>
e 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
and `python-pip`, 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, A
al system pip modules. It *does not belong* in
> /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
> infrastructu
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
___
devel mailing list -- devel@lis
g utilities can be a module!", and
we'll see both tox and the additional Python runtimes move to that
maintenance model. In the long run, that's almost certainly a good
idea. Today though, the best possible developer experience that Fedora
can provide is for "dnf install tox&qu
onal 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.
--
Ni
system packages. Containers also help a lot
here, as we can use a layered model where we use the system package
manager to install the language runtime, and then the runtime plugin
manager (which is effectively what pip, gem, maven, npm, etc are) to
install the language level components.
Regards,
N
quot; model, where folks put a package up in COPR with bundled
components, and then either keep it there indefinitely, or collaborate
with others on the unbundling effort.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
--
devel mailing li
uot; week for the E&S meeting time, but
for next week, I'm hoping to have some more coherent thoughts relating
to the user level package management and package review process
redesign topics, updated for a range of discussions we had at Flock
last week.
Cheers,
Nick.
--
Nick Coghlan
On 23 Jul 2015 01:17, "Adam Samalik" wrote:
>
> Hi everyone,
>
> I updated the prototype and tried apply your feedback:
https://developer-phracek.rhcloud.com/
Very nice!
> What I would like to do next? Ideally, if you find some time, I would
like to have a session with you, people interested in
language specific sections in the proposed developer portal
(https://fedoraproject.org/wiki/Websites/Developer) could potentially
cover those simple cases, and then provide pointers to the guidelines
for handling the more complex cases.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisba
efore
human reviewers even need to get involved at all.
That way potential packagers wouldn't be left in limbo waiting for
potential sponsors to provide feedback, and potential sponsors would
be able to focus their attention on potential packagers that have
already demonstrated
nding the change
in Rawhide so we get an itemised list of which packages failed to
rebuild and the associated mock build logs.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
h package review 100% clean, and then the next day go and
> edit it to do all sorts of horrible things, and odds are really good
> that no one will call me on it. This generally isn't due to malice, but
> the rules are complicated and the guidelines long — it's easy for al
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/05/2013 07:15 AM, Tim Flink wrote:
> On Fri, 01 Nov 2013 18:43:32 +1000 Nick Coghlan
> wrote:
>
> On 11/01/2013 05:23 PM, Tim Flink wrote:
>>>> I'm fine with either direction for now. My hesitation on
>>
o it's a
fairly extreme approach to the problem of inconsistent method names that
prevent duck-typing. It's generally preferable to use a wrapper class or
a custom subclass to adapt between the two APIs at the point of use
rather than changing state that can be seen by every other modul
47 matches
Mail list logo
