Opened 6 years ago

Closed 5 years ago

#20472 closed defect (wontfix)

Remove old-style PyX package

Reported by: novoselt Owned by:
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: packages: optional Keywords:
Cc: dimpase, vbraun Merged in:
Authors: Reviewers: Andrey Novoseltsev
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description

See https://groups.google.com/d/topic/sage-devel/9kx4zsnMYlQ/discussion with the summary: we have an ancient version of PyX as an old-style optional package which seems to break pip at least in some cases. On the other hand it is possible to install a newer version through pip directly.

Change History (17)

comment:1 Changed 6 years ago by novoselt

  • Status changed from new to needs_review

comment:2 Changed 6 years ago by jdemeyer

  • Status changed from needs_review to needs_info

You forgot to push...

comment:3 Changed 6 years ago by dimpase

there isn't anything to push, as far as I know, as it's an old style package...

comment:4 follow-up: Changed 6 years ago by jdemeyer

  • Status changed from needs_info to needs_review
  • Summary changed from Remove PyX optional package to Remove old-style PyX package

Then why not simply add a new-style pip package for PyX?

comment:5 in reply to: ↑ 4 Changed 6 years ago by dimpase

Replying to jdemeyer:

Then why not simply add a new-style pip package for PyX?

what is the point of this?

This is pure bloat - why not add a package for everything in pypi?!

comment:6 follow-up: Changed 6 years ago by dimpase

By the way, I don't even get what you mean, really. Do we even have any new-style optional packages without mirrored tarballs, just pypi-installable?

comment:7 in reply to: ↑ 6 ; follow-ups: Changed 6 years ago by jdemeyer

Replying to dimpase:

Do we even have any new-style optional packages without mirrored tarballs, just pypi-installable?

Yes, we do. See mercurial for one example.

comment:8 in reply to: ↑ 7 Changed 6 years ago by dimpase

Replying to jdemeyer:

Replying to dimpase:

Do we even have any new-style optional packages without mirrored tarballs, just pypi-installable?

Yes, we do. See mercurial for one example.

Remove it, too!

comment:9 in reply to: ↑ 7 Changed 6 years ago by dimpase

Replying to jdemeyer:

Replying to dimpase:

Do we even have any new-style optional packages without mirrored tarballs, just pypi-installable?

Yes, we do. See mercurial for one example.

No idea what you mean. It's broken, anyway:

$ sage -p mercurial
Attempting to download package mercurial
Downloading the Sage mirror list
...
Fastest mirror: http://www.mirrorservice.org/sites/www.sagemath.org/
>>> Checking online list of optional packages.
>>> Checking online list of experimental packages.
>>> Checking online list of huge packages.
Error: could not find a package matching mercurial
       Try 'sage --package list' to see the available packages
       Did you mean: brial?

comment:10 Changed 6 years ago by jdemeyer

Why are you using sage -p to install packages? That's a low-level command that you should only use "if you know what you're doing". With sage -i mercurial, it works fine.

comment:11 follow-ups: Changed 6 years ago by dimpase

Is there any rationale for having all that

build/pkgs/blah/

with the only content build/pkgs/blah/type, so that one can do sage -i blah, whereas one could just as well do sage --pip install blah with the same effect?

comment:12 in reply to: ↑ 11 ; follow-up: Changed 6 years ago by jdemeyer

Replying to dimpase:

Is there any rationale for having all that

build/pkgs/blah/

with the only content build/pkgs/blah/type, so that one can do sage -i blah, whereas one could just as well do sage --pip install blah with the same effect?

User-friendlyness of having one interface (sage -i PKGNAME) instead of multiple ones.

comment:13 in reply to: ↑ 12 Changed 6 years ago by dimpase

Replying to jdemeyer:

Replying to dimpase:

Is there any rationale for having all that

build/pkgs/blah/

with the only content build/pkgs/blah/type, so that one can do sage -i blah, whereas one could just as well do sage --pip install blah with the same effect?

User-friendlyness of having one interface (sage -i PKGNAME) instead of multiple ones.

given that sage --pip install blah is available, you create more complexity by adding sage -i blah

comment:14 in reply to: ↑ 11 Changed 6 years ago by dimpase

Replying to dimpase:

Is there any rationale for having all that

build/pkgs/blah/

with the only content build/pkgs/blah/type, so that one can do sage -i blah, whereas one could just as well do sage --pip install blah with the same effect?

besides, there is not telling whether what you install with sage -i can be uninstalled. At least in the case of sage --pip you can uninstall! And you still talk about user-friendliness...

see also We can merge the current to appease the cargo cultists and finally get rid of some of the broken packages, but its not entirely satisfactory.

Last edited 6 years ago by dimpase (previous) (diff)

comment:15 Changed 5 years ago by vdelecroix

see also #21076

comment:16 Changed 5 years ago by jdemeyer

  • Authors Andrey Novoseltsev deleted
  • Milestone changed from sage-7.2 to sage-duplicate/invalid/wontfix
  • Reviewers set to Andrey Novoseltsev
  • Status changed from needs_review to positive_review

Duplicate of #19220.

comment:17 Changed 5 years ago by embray

  • Resolution set to wontfix
  • Status changed from positive_review to closed

Determined to be invalid/duplicate/wontfix (closing as "wontfix" as a catch-all resolution).

Note: See TracTickets for help on using tickets.