Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove old-style PyX package #20472

Closed
novoselt opened this issue Apr 20, 2016 · 18 comments
Closed

Remove old-style PyX package #20472

novoselt opened this issue Apr 20, 2016 · 18 comments

Comments

@novoselt
Copy link
Member

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.

CC: @dimpase @vbraun

Component: packages: optional

Reviewer: Andrey Novoseltsev

Issue created by migration from https://trac.sagemath.org/ticket/20472

@jdemeyer
Copy link

comment:2

You forgot to push...

@dimpase
Copy link
Member

dimpase commented Apr 20, 2016

comment:3

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

@jdemeyer
Copy link

comment:4

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

@jdemeyer jdemeyer changed the title Remove PyX optional package Remove old-style PyX package Apr 20, 2016
@dimpase
Copy link
Member

dimpase commented Apr 20, 2016

comment:5

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?!

@dimpase
Copy link
Member

dimpase commented Apr 20, 2016

comment:6

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?

@jdemeyer
Copy link

comment:7

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.

@dimpase
Copy link
Member

dimpase commented Apr 20, 2016

comment:8

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!

@dimpase
Copy link
Member

dimpase commented Apr 20, 2016

comment:9

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?

@jdemeyer
Copy link

comment:10

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.

@dimpase
Copy link
Member

dimpase commented Apr 20, 2016

comment:11

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?

@jdemeyer
Copy link

comment:12

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.

@dimpase
Copy link
Member

dimpase commented Apr 20, 2016

comment:13

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

@dimpase
Copy link
Member

dimpase commented Apr 20, 2016

comment:14

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.

@videlec
Copy link
Contributor

videlec commented Jul 23, 2016

comment:15

see also #21076

@jdemeyer
Copy link

Reviewer: Andrey Novoseltsev

@jdemeyer
Copy link

Changed author from Andrey Novoseltsev to none

@jdemeyer
Copy link

comment:16

Duplicate of #19220.

@jdemeyer jdemeyer removed this from the sage-7.2 milestone Jul 24, 2016
@embray
Copy link
Contributor

embray commented Aug 30, 2016

comment:17

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants