09.04.2017 19:15, William L. Thomson Jr. пишет:
> Not sure if this is practical, it may be less work if the use of
> Python and Ruby versions ( maybe others ) is reversed. Rather than
> adding all the versions that the ebuild supports. What if it only
> included versions it did not support?
It wa
On Thu, 20 Apr 2017 10:49:04 -0700
Christopher Head wrote:
> >Usually when writing new code, you use the latest version of stuff. Not
> >always but usually best. If anything make code support older while
> >targeting newer.
>
> No, not how I develop. I always start by determining my target aud
On Thu, 20 Apr 2017 10:49:04 -0700
Christopher Head wrote:
>
> >If your writing new python code against say 3.4 and not 3.6. Not sure
> >about that... Seems like it would keep things bound to older versions
> >and never let things move forward.
>
> Not true. I will certainly move forward when a
On April 10, 2017 11:12:10 AM PDT, "William L. Thomson Jr."
wrote:
>Are you running stable? There are other versions in tree. 3.4, 3.5,
>3.6. If you were running unstable, you would have 4 pythons, including
>2.7. That you only have 2 seems like you are running stable.
Yep. Absolutely. I bring i
On Tue, 11 Apr 2017 10:56:51 +1200
Kent Fredric wrote:
> On Mon, 10 Apr 2017 18:35:13 -0400
>
> I've run a box with it since 2008. More pain, less help. Have to write
> my own tools just for keeping things up-to-date.
This was not an update thing. This was some feature you could run it
and it p
On Mon, 10 Apr 2017 18:35:13 -0400
"William L. Thomson Jr." wrote:
> Have you worked with paludis? If you can get that setup it should give
> you more useful output in less time. Ciaran would know there, and maybe
> some others.
>
> > Hence, that's the sort of problem I'm more inclined to throw
On Tue, 11 Apr 2017 00:44:30 +0300
Mart Raudsepp wrote:
> Ühel kenal päeval, E, 10.04.2017 kell 17:33, kirjutas William L.
> Thomson Jr.:
> > Add a new Java version and recompiling packages with it, will also
> > immediately show breakage if any.
> >
> > If your saying Python code is of higher q
On Mon, 10 Apr 2017 23:56:04 +0200
>
> Except that the packages don't get recompiled unless you take manual
> action to recompile them. If you fail at this action, you may end up
> having broken software because the rebuild has not been complete.
Which is the duty of the team, or whom ever is addi
On Tue, 11 Apr 2017 10:09:51 +1200
Kent Fredric wrote:
> On Mon, 10 Apr 2017 16:01:55 -0400
>
> You're running ~arch, I recall.
Yes but most servers run stable. Though they have some ~arch packages.
I may move to fully ~arch. I think stabilization on Gentoo is a
misnomer. Usually newer stuff ten
On Tue, 11 Apr 2017 03:29:25 +0700
"Vadim A. Misbakh-Soloviov" wrote:
> The purpose of TARGETS is that package holds only that TARGETs that it was
> tested to work against
Targets are more than that.
Targets also regulate compilation stage for concurrency.
For instance:
If you have 2 pythons
On Mon, 10 Apr 2017 16:01:55 -0400
"William L. Thomson Jr." wrote:
> You still have
> adding new, and the end user experience.
You're running ~arch, I recall.
This means adding new is slow for arch users.
But it also means there's a clear line in the sand when something can be
stabilized.
~a
On Mon, 10 Apr 2017 23:33:06 +0200
Michał Górny wrote:
>
> So, to summarize: you want to destroy a reasonably reliable dependency
> system in favor of thing that randomly explodes because you failed at
> hacking at it?
Interesting comments. If the system is so well engineered. Why am I
having to
On pon, 2017-04-10 at 17:33 -0400, William L. Thomson Jr. wrote:
> On Mon, 10 Apr 2017 22:43:18 +0200
> Michał Górny wrote:
> >
> > The difference is in quality expectations. We did Python this way to
> > make sure things will work, and all obvious breakage will immediately
> > be caught. Your al
On Mon, 10 Apr 2017 12:03:51 -0400
"William L. Thomson Jr." wrote:
> That is ALLOT of work to fiddle
Unrelated to thread and is not intended as a "I'm better because I grammar
well" thing,
but this drives me nuts and I've bitten my tongue on it for months.
But you use that word that isn't a w
Ühel kenal päeval, E, 10.04.2017 kell 17:33, kirjutas William L.
Thomson Jr.:
> Add a new Java version and recompiling packages with it, will also
> immediately show breakage if any.
>
> If your saying Python code is of higher quality than Java. I would
> digress heavily on that. You have leniency
On Mon, 10 Apr 2017 22:43:18 +0200
Michał Górny wrote:
>
> The difference is in quality expectations. We did Python this way to
> make sure things will work, and all obvious breakage will immediately
> be caught. Your alternative does not provide for that.
Add a new Java version and recompiling
On pon, 2017-04-10 at 17:18 -0400, William L. Thomson Jr. wrote:
> > Python used not to use TARGETS. The results were random
> > incompatibilities between packages that were hard to track and random
> > breakage. Now we're past that. But I can understand it's not the
> > Gentoo of your times where
On Mon, 10 Apr 2017 11:52:02 -0400
"William L. Thomson Jr." wrote:
> >
> > Meanwhile, you cannot build two parts of a given python dependency
> > chain with different pythons, nor different perls.
>
> True but this is not changing how things work, just reversing.
You mean going back to the ol
On Tue, 11 Apr 2017 03:48:37 +0700
"Vadim A. Misbakh-Soloviov" wrote:
> > or PHP.
>
> Wouldn't you be so kind to re-check this part, please? :)
>
I was incorrect, PHP has targets. The systems I have it on just have
PHP_TARGET=""
Which is the wild card solution I was saying was the only he
On Tue, 11 Apr 2017 04:17:31 +0700
"Vadim A. Misbakh-Soloviov" wrote:
> Also,
>
> > Its an update issue. You set a target to say Ruby 24. But something
> > wants Ruby23. It could be it only builds with ruby23. Or more than
> > likely no one has gotten around to adding it to the package. Since
>
On Mon, 10 Apr 2017 22:51:11 +0200
Michał Górny wrote:
>
> I'm sorry but do you even use Gentoo, these days? Like the real
> Gentoo, not just some little part you've installed years ago and then
> modified only Java stuff in it?
Um yes... Maybe someday you will learn to stop assuming
Having
Also,
> Its an update issue. You set a target to say Ruby 24. But something
> wants Ruby23. It could be it only builds with ruby23. Or more than
> likely no one has gotten around to adding it to the package. Since for
> every new version. EVERY ebuild must be touched.
As I said above, this only
On pon, 2017-04-10 at 16:40 -0400, William L. Thomson Jr. wrote:
> On Tue, 11 Apr 2017 03:29:25 +0700
> "Vadim A. Misbakh-Soloviov" wrote:
>
> > Am I right in assumption that you arguing about *_TARGETS rework to
> > be enabled by default for packages that was not tested on this
> > TARGETs with
> or PHP.
Wouldn't you be so kind to re-check this part, please? :)
On pon, 2017-04-10 at 16:33 -0400, William L. Thomson Jr. wrote:
> On Mon, 10 Apr 2017 23:21:24 +0300
> Mart Raudsepp wrote:
> >
> > The user experience is suboptimal either way. Some ideas to improve
> > that seems to be e.g something like Kent brought up. But all this
> > requires manpower and
On Tue, 11 Apr 2017 03:29:25 +0700
"Vadim A. Misbakh-Soloviov" wrote:
> Am I right in assumption that you arguing about *_TARGETS rework to
> be enabled by default for packages that was not tested on this
> TARGETs with ... hardness of packaging java software?..
I think TARGETS should not exist.
On Mon, 10 Apr 2017 23:21:24 +0300
Mart Raudsepp wrote:
>
> The user experience is suboptimal either way. Some ideas to improve
> that seems to be e.g something like Kent brought up. But all this
> requires manpower and so on to actually do; potentially also limiting
> potential manpower to whom h
Ühel kenal päeval, E, 10.04.2017 kell 16:17, kirjutas William L.
Thomson Jr.:
> On Mon, 10 Apr 2017 16:01:55 -0400
> "William L. Thomson Jr." wrote:
> >
> > Ok I concede on removing older versions. Lets put old version
> > aside.
> >
> > What about adding new? You still have to add the new versi
Am I right in assumption that you arguing about *_TARGETS rework to be enabled
by default for packages that was not tested on this TARGETs with ... hardness
of packaging java software?..
Or does it just argmentum ad verecundiam (with argumentum ad hominem
partially)?
And yes, I personally pack
To back up a bit. I package Java why do I care about Python and Ruby?
1. Its annoying as a user to fiddle with targets, short of doing a wild
card and having multiple versions.
2. Unlike most other languages. Java has support for other languages.
Running PHP, Python, and Ruby on the JVM.
This ja
Ühel kenal päeval, E, 10.04.2017 kell 16:01, kirjutas William L.
Thomson Jr.:
> On Mon, 10 Apr 2017 22:51:35 +0300
> Mart Raudsepp wrote:
> >
> > After testing they actually work with the new version, instead of
> > throwing known breakages onto ~arch users.
>
> Ebuilds cannot use the new versio
On Mon, 10 Apr 2017 16:01:55 -0400
"William L. Thomson Jr." wrote:
>
> Ok I concede on removing older versions. Lets put old version aside.
>
> What about adding new? You still have to add the new version to
> PYTHON_COMPAT in each ebuild right?
>
> What about users? Do they need do anything if
> painless option for users.
Well... If a bit of mind work is pain... So, then I'd say that Gentoo is not
about avoiding such pain.
Did you hear about Gentoo Philosophy?
It says that point of Gentoo to appear was to give users possibility to make
exact "tool" they wants to use, but not decide
On Mon, 10 Apr 2017 22:51:35 +0300
Mart Raudsepp wrote:
>
> After testing they actually work with the new version, instead of
> throwing known breakages onto ~arch users.
Ebuilds cannot use the new version till it is added to their
PYTHON_COMPAT correct?
There does not seem to be any way around
On Mon, 10 Apr 2017 20:38:22 +0100
Ciaran McCreesh wrote:
> On Tue, 11 Apr 2017 02:31:54 +0700
> "Vadim A. Misbakh-Soloviov" wrote:
> > > If Java can do it, so can others.
> >
> > And here I come with my 5¢. And my point here is simple:
> >
> > No, Java (Team) can't.
>
> Ah, you appear
Ühel kenal päeval, E, 10.04.2017 kell 15:38, kirjutas William L.
Thomson Jr.:
> On Mon, 10 Apr 2017 21:57:10 +0300
> Mart Raudsepp wrote:
>
> > Ühel kenal päeval, E, 10.04.2017 kell 14:44, kirjutas William L.
> > Thomson Jr.:
> > > Again go modify a few hundred python packages to remove say 3.4.
On 10/04/2017 19:58, Christopher Head wrote:
> On April 9, 2017 7:04:13 PM PDT, "William L. Thomson Jr."
> wrote:
>> The present system is a PITA for users. Fiddling with adding/removing
>> targets for Python/Ruby.
>
> As an ordinary user, that does sound like a real annoyance. As an ordinary
>
On Tue, 11 Apr 2017 02:31:54 +0700
"Vadim A. Misbakh-Soloviov" wrote:
> > If Java can do it, so can others.
>
> And here I come with my 5¢. And my point here is simple:
>
> No, Java (Team) can't.
Ah, you appear to be thinking of the Gentoo Java team as it currently
exists, rather than the myt
On Mon, 10 Apr 2017 21:57:10 +0300
Mart Raudsepp wrote:
> Ühel kenal päeval, E, 10.04.2017 kell 14:44, kirjutas William L.
> Thomson Jr.:
> > Again go modify a few hundred python packages to remove say 3.4. I
> > think about 10-20 ebuilds in. You will be scripting and looking for
> > another way.
> If Java can do it, so can others.
And here I come with my 5¢. And my point here is simple:
No, Java (Team) can't.
Every time I come to Java team with some report they suggest (as joke,
partially) to become a "full" developer (but not a contributor) and take care
of this by myself.
And the
Ühel kenal päeval, E, 10.04.2017 kell 14:44, kirjutas William L.
Thomson Jr.:
> Again go modify a few hundred python packages to remove say 3.4. I
> think about 10-20 ebuilds in. You will be scripting and looking for
> another way
No, for that you simple remove python3_4 from _PYTHON_ALL_IMPLS
On Mon, 10 Apr 2017 20:10:44 +0200
Michał Górny wrote:
>
> I don't see how attempting to discredit me is a fact regarding your
> idea.
You may assume what ever. I simply pointed out you are 1 of on a team
of many. I have no requirement or duty to bring my ideas to you. If
anything maybe the team
On Mon, 10 Apr 2017 10:58:10 -0700
Christopher Head wrote:
> On April 9, 2017 7:04:13 PM PDT, "William L. Thomson Jr."
> wrote:
> >The present system is a PITA for users. Fiddling with adding/removing
> >targets for Python/Ruby.
>
> As an ordinary user, that does sound like a real annoyance.
(CC-ing comrel@)
On pon, 2017-04-10 at 13:49 -0400, William L. Thomson Jr. wrote:
> and Python support in Gentoo (which I use) a mess long-term. What is
> > even worse, you do that without even talking to the Python team, or
> > even bothering to CC them -- what you do instead is start a public
>
On April 9, 2017 7:04:13 PM PDT, "William L. Thomson Jr."
wrote:
>The present system is a PITA for users. Fiddling with adding/removing
>targets for Python/Ruby.
As an ordinary user, that does sound like a real annoyance. As an ordinary
user, I also never do it. I don’t have any targets set by
On pon, 2017-04-10 at 15:21 +0200, Dirkjan Ochtman wrote:
> On Mon, Apr 10, 2017 at 8:37 AM, Michał Górny wrote:
> > It is always nice when a person who:
>
> Please stop the sarcasm. While I understand the reaction, the idea in
> itself does not seem totally crazy to me, and it seems useful to ha
On Mon, 10 Apr 2017 19:14:32 +0200
Michał Górny wrote:
> I would love to avoid you. However, you make this impossible via
> trying to make the life of Python team (which I am part of) a misery,
I do not force you to reply. Clearly you are not able to control
yourself from replying. I do with fac
On pon, 2017-04-10 at 12:03 -0400, William L. Thomson Jr. wrote:
> On Mon, 10 Apr 2017 08:37:34 +0200
> Michał Górny wrote:
> >
> > It is always nice when a person who:
>
> Starts off with insults and rudeness... Why I avoid you and I have
> requested MULITPLE times you just avoid me. Almost did
On Mon, 10 Apr 2017 08:37:34 +0200
Michał Górny wrote:
>
> It is always nice when a person who:
Starts off with insults and rudeness... Why I avoid you and I have
requested MULITPLE times you just avoid me. Almost did not reply, but
unlike your comments I will stick to FACTS.
> a. did not bother
On Mon, 10 Apr 2017 16:35:48 +1200
Kent Fredric wrote:
>
> Meanwhile, you cannot build two parts of a given python dependency
> chain with different pythons, nor different perls.
True but this is not changing how things work, just reversing.
> Right, but this is impossible with Ruby, Python, and
On Mon, 10 Apr 2017 10:57:43 -0400
>
> You are: when you find out that a stable package doesn't work with
> the next version of python, you have to figure out who the maintainer
> of that package is, and file a bug.
That is how things are done for Java, and I think Perl as well. There
tend to be
On 04/09/2017 08:58 PM, William L. Thomson Jr. wrote:
I am NOT talking about stabilization at all. Simple reducing the burden
of adding targets to ebuild, and users having to fiddle with targets as
they come and go.
You are: when you find out that a stable package doesn't work with the
next
On Mon, Apr 10, 2017 at 8:37 AM, Michał Górny wrote:
> It is always nice when a person who:
Please stop the sarcasm. While I understand the reaction, the idea in
itself does not seem totally crazy to me, and it seems useful to have
a discussion on its merits.
At the same time, I would not consid
Dnia 9 kwietnia 2017 18:15:56 CEST, "William L. Thomson Jr."
napisał(a):
>Not sure if this is practical, it may be less work if the use of
>Python and Ruby versions ( maybe others ) is reversed. Rather than
>adding all the versions that the ebuild supports. What if it only
>included versions it d
On Mon, 2017-04-10 at 00:04 +0100, James Le Cuirot wrote:
> People thought the sky would fall when 2.4 deprecated Fixnum
> and
> Bignum. It really didn't. It's still just a warning right now but I
> haven't seen that warning since it was dealt with in Rails.
>
This change broke the rspec test sui
On Sun, 9 Apr 2017 22:04:13 -0400
"William L. Thomson Jr." wrote:
> This has never been the case with Java.
Its not a problem with C binaries either, because you have a discrete
compile time, and language level interop between compiled binary forms.
Meanwhile, you cannot build two parts of a gi
On Mon, 10 Apr 2017 13:38:58 +1200
Kent Fredric wrote:
>
> When you reverse this, you introduce a situation where adding a new
> version across the board creates a new skeleton-tree of support.
FYI, this is how it is when a new Java JDK comes out. When 1.5 came
out, if 1.4 code had issues compili
On Sun, 9 Apr 2017 12:15:56 -0400
"William L. Thomson Jr." wrote:
>
> The approach mentioned above, if the packages do not have issue. I
> could go ahead and switch to ruby24 and pyton 3.6 across the board.
> Which I cannot do now till a bunch of ebulids have their targets
> increased.
>
This
On Sun, 9 Apr 2017 19:59:22 -0400
Michael Orlitzky wrote:
>
> How do you plan to test a thousand packages against the new version
> of python, and then revision/stabilize all of the broken ones
> immediately? Or is the plan to just break everyone's systems, and ask
> them to report bugs for the th
On 10/04/2017 01:59, Michael Orlitzky wrote:
On 04/09/2017 07:15 PM, William L. Thomson Jr. wrote:
If the package failed, all that would need to be done kinda like now is
a given variable modified in the ebuild. Just marking what ever it did
not work with. As mentioned that could be done via
On 04/09/2017 07:15 PM, William L. Thomson Jr. wrote:
If the package failed, all that would need to be done kinda like now is
a given variable modified in the ebuild. Just marking what ever it did
not work with. As mentioned that could be done via my
ebuild-batcher[1], though same functionality
On Sun, 9 Apr 2017 15:20:02 -0700
Brian Dolbec wrote:
>
> This could be partially automated using buildbot. The easiest would
> be for pkgs containing working test suites. Those that pass could be
> auto-enabled with that python with ~arch keywords. I think if a
> stable pkg is to be added the
On Sun, 9 Apr 2017 23:44:50 +0200
Kristian Fiskerstrand wrote:
> On 04/09/2017 06:15 PM, William L. Thomson Jr. wrote:
> > Not sure if this is practical, it may be less work if the use of
> > Python and Ruby versions ( maybe others ) is reversed. Rather than
> > adding all the versions that the e
On Sun, 9 Apr 2017 12:15:56 -0400
"William L. Thomson Jr." wrote:
> Python 2.7 stuff aside. I am not sure how many Python and Ruby packages
> break with a newer release. In pythons case I think once they support
> Python 3.x, there is little chance if it breaking with further 3.x
> releases. Not
On 10/04/2017 00:20, Brian Dolbec wrote:
On Sun, 9 Apr 2017 23:36:18 +0200
Francesco Riosa wrote:
On 09/04/2017 18:15, William L. Thomson Jr. wrote:
Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all
On 09/04/2017 23:52, Michael Orlitzky wrote:
On 04/09/2017 12:15 PM, William L. Thomson Jr. wrote:
Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all the versions that the ebuild supports. What if it on
On Sun, 9 Apr 2017 17:52:44 -0400
Michael Orlitzky wrote:
> On 04/09/2017 12:15 PM, William L. Thomson Jr. wrote:
> > Not sure if this is practical, it may be less work if the use of
> > Python and Ruby versions ( maybe others ) is reversed. Rather than
> > adding all the versions that the ebuild
On 09/04/2017 23:44, Kristian Fiskerstrand wrote:
On 04/09/2017 06:15 PM, William L. Thomson Jr. wrote:
Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all the versions that the ebuild supports. What if
On Sun, 9 Apr 2017 23:36:18 +0200
Francesco Riosa wrote:
> On 09/04/2017 18:15, William L. Thomson Jr. wrote:
> > Not sure if this is practical, it may be less work if the use of
> > Python and Ruby versions ( maybe others ) is reversed. Rather than
> > adding all the versions that the ebuild sup
On 04/09/2017 12:15 PM, William L. Thomson Jr. wrote:
Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all the versions that the ebuild supports. What if it only
included versions it did not support?
Even
On 04/09/2017 06:15 PM, William L. Thomson Jr. wrote:
> Not sure if this is practical, it may be less work if the use of
> Python and Ruby versions ( maybe others ) is reversed. Rather than
> adding all the versions that the ebuild supports. What if it only
> included versions it did not support?
On 09/04/2017 18:15, William L. Thomson Jr. wrote:
Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all the versions that the ebuild supports. What if it only
included versions it did not support?
Rational
72 matches
Mail list logo
