Re: Bug#999415: transition: pandas 1.1 -> 1.3 - to unstable now or not?

2021-11-28 Thread Scott Talbert

On Sun, 28 Nov 2021, Rebecca N. Palmer wrote:

After build-testing about half of the reverse dependencies, failures that 
look new-pandas-related are cfgrib #1000726, joypy #1000727, python-skbio 
#1000752, and maybe hyperspy (not filed yet).


python-skbio and hyperspy already FTBFS for unrelated reasons (but fail more 
tests with new pandas), and joypy looks trivially fixable.


Given this and expecting to find a similar number in the other half, against 
pandas 1.3 working on python3.10 while 1.1 doesn't (#1000422), would you 
prefer to have pandas 1.3 in unstable now, or not?


My vote would be: go for it, but then again, I don't maintain any of 
pandas BDs.


Thanks,
Scott



Re: Bug#999415: transition: pandas 1.1 -> 1.3 - to unstable now or not?

2021-11-28 Thread Rebecca N. Palmer
After build-testing about half of the reverse dependencies, failures 
that look new-pandas-related are cfgrib #1000726, joypy #1000727, 
python-skbio #1000752, and maybe hyperspy (not filed yet).


python-skbio and hyperspy already FTBFS for unrelated reasons (but fail 
more tests with new pandas), and joypy looks trivially fixable.


Given this and expecting to find a similar number in the other half, 
against pandas 1.3 working on python3.10 while 1.1 doesn't (#1000422), 
would you prefer to have pandas 1.3 in unstable now, or not?




Re: Bug#999415: transition: pandas 1.1 -> 1.3

2021-11-21 Thread Rebecca N. Palmer

Control: block 996584 by -1

On 21/11/2021 06:30, Graham Inggs wrote:

It might be easier to upgrade to 1.2.4 first, then 1,3,x later.


Probably not, given that we're now trying to add Python 3.10 support 
(#996584), and pandas upstream's work on that is recent (maybe still 
unfinished): https://github.com/pandas-dev/pandas/issues/41940


The 1.3.x currently in Salsa built last time I tried (before Python 
3.10), but is (intentionally, to avoid FTBFS) missing some 
documentation, and I haven't tested the reverse dependencies yet.




Re: transition: pandas 1.1 -> 1.3

2021-11-20 Thread Graham Inggs
It might be easier to upgrade to 1.2.4 first, then 1,3,x later.



Re: transition: pandas 1.1 -> 1.3

2021-11-11 Thread Rebecca N. Palmer
I was already planning to try a build+autopkgtest of the reverse 
dependencies, and probably an upload to experimental (it's also common 
for pandas to fail a few tests on non-amd64), at some point, but not 
just yet. (The last time I did this was #969650.)


Thanks for the tools suggestions.

I am currently working on pandas itself: I suspect the documentation 
isn't the only issue.




Re: transition: pandas 1.1 -> 1.3

2021-11-11 Thread Andreas Tille
Hi Rebecca,

Am Thu, Nov 11, 2021 at 09:31:12PM + schrieb Rebecca N. Palmer:
> I was already planning to try a build+autopkgtest of the reverse
> dependencies, and probably an upload to experimental (it's also common for
> pandas to fail a few tests on non-amd64), at some point, but not just yet.
> (The last time I did this was #969650.)
> 
> Thanks for the tools suggestions.
> 
> I am currently working on pandas itself: I suspect the documentation isn't
> the only issue.

Thanks a lot for taking over

 Andreas.


-- 
http://fam-tille.de



Re: transition: pandas 1.1 -> 1.3

2021-11-11 Thread Nilesh Patra



On 11 November 2021 5:44:09 am IST, Drew Parsons  wrote:
>On 2021-11-10 20:19, Rebecca N. Palmer wrote:
>> Source: pandas
>> 
>> On 10/11/2021 17:14, Andreas Tille wrote:
>>> pandas is lagging behind upstream by several versions.  I guess we
>>> should try to get in sync with upstream a bit more.
>> 
>> Yes, but please don't upload this yet: it's common for a pandas
>> upgrade to break reverse dependencies.
>
>
>If the new pandas builds successfully, then certainly upload it to 
>experimental first.  We can test dependencies from there.

That makes sense, but other than that, I'd really recommend also to build the 
reverse-"build"-deps with ruby-team/meta or ratt.

Uploading to experimental and checking Britney's pseudoexcuses would only 
warrant for failing autopkgtests in other packages because of new pandas.

Regards,
Nilesh



Re: transition: pandas 1.1 -> 1.3

2021-11-11 Thread Andreas Tille
Hi,

Am Thu, Nov 11, 2021 at 07:17:27PM +0530 schrieb Nilesh Patra:
> 
> >If the new pandas builds successfully, then certainly upload it to 
> >experimental first.  We can test dependencies from there.
   ^^
 
> That makes sense, but other than that, I'd really recommend also to build the 
> reverse-"build"-deps with ruby-team/meta or ratt.
> 
> Uploading to experimental and checking Britney's pseudoexcuses would only 
> warrant for failing autopkgtests in other packages because of new pandas.

That's all fine but the precondition is not fulfilled (see above) and we
need people who fix the build first ... than we can follow all those
hints.  My initial attempt was just a kickstart to get something happen
but I do not intend to continue working on this in this month (may be
year).

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: transition: pandas 1.1 -> 1.3

2021-11-10 Thread Drew Parsons

On 2021-11-10 20:19, Rebecca N. Palmer wrote:

Source: pandas

On 10/11/2021 17:14, Andreas Tille wrote:

pandas is lagging behind upstream by several versions.  I guess we
should try to get in sync with upstream a bit more.


Yes, but please don't upload this yet: it's common for a pandas
upgrade to break reverse dependencies.



If the new pandas builds successfully, then certainly upload it to 
experimental first.  We can test dependencies from there.


Drew



transition: pandas 1.1 -> 1.3

2021-11-10 Thread Rebecca N. Palmer

Source: pandas
Version: 1.1.5+dfsg-2
Severity: wishlist

On 10/11/2021 17:14, Andreas Tille wrote:

pandas is lagging behind upstream by several versions.  I guess we
should try to get in sync with upstream a bit more.


Yes, but please don't upload this yet: it's common for a pandas upgrade 
to break reverse dependencies.



The package does not build yet since the documentation needs sphinx_panels.
On 10/11/2021 18:32, Timo Röhling wrote> Maybe, as a compromise, we can 
cut out all the notebooks^H bells and

whistles and limit the offline documentation to the API reference
itself, which is arguably the most useful part? I don't know
how easy it is to trim down the documentation, though.


The pandas (and probably statsmodels) documentation already is modified 
to build with fewer dependencies - see sphinx_no_pandas_theme.patch.