Bug 1010479

python-ase has a branch (https://svn.fysik.dtu.dk/projects/ase/branches/cli/tools/) which uses ase-gui instead of ag, but it may be at least several months before it gets merged to the trunk and a new release of python-ase made.
Note that python-ase' ag is not simply a gui starter - it accepts also command
line arguments and can be used without any gui, e.g.:
https://wiki.fysik.dtu.dk/ase/ase/gui/basics.html#plotting-data-from-the-command-line

The convention for atomic symbols is to capitalize the first letter
http://en.wikipedia.org/wiki/Chemical_symbol so the_silver_searcher could
in the first place use Ag instead of ag.
I see there are several packages that install executables
with capitalized names `LC_ALL=C ls /usr/bin/[[:upper:]]*`.

Due to the fact that the the_silver_searcher is being packaged for Fedora
right now, we could temporarily have Ag as the name for it in Fedora,
and define an alias in /etc/profile.d/ag.*sh (as which does).
It's OK for me the python-ase ag name is overwritten by the_silver_searcher
for these couple of months, as long as we use this bug to document what happens.

After the (hopefully already) next python-ase release the only remaining thing 
to be done will be to restore the ag name and remove /etc/profile.d/ag.*sh,
and close this bug as resolved.

Thank you for your feedback, this very helpful :)

(In reply to marcindulak from comment #1)
> python-ase has a branch
> (https://svn.fysik.dtu.dk/projects/ase/branches/cli/tools/) which uses
> ase-gui instead of ag, but it may be at least several months before it gets
> merged to the trunk and a new release of python-ase made.

This is great news, could we get in touch with upstream to ask how much time it should take before it's merged and released ? (an estimation)

> Note that python-ase' ag is not simply a gui starter - it accepts also
> command
> line arguments and can be used without any gui, e.g.:
> https://wiki.fysik.dtu.dk/ase/ase/gui/basics.html#plotting-data-from-the-
> command-line

This is unfortunate for the_silver_searcher, but this is interesting to know.

> The convention for atomic symbols is to capitalize the first letter
> http://en.wikipedia.org/wiki/Chemical_symbol so the_silver_searcher could
> in the first place use Ag instead of ag.
> I see there are several packages that install executables
> with capitalized names `LC_ALL=C ls /usr/bin/[[:upper:]]*`.

Yes but, my canonical example (mercurial) uses hg not because people didn't know mercury's symbol is Hg. Maybe they don't but I guess this is because lowercase hg is more user-friendly on the CLI.

> Due to the fact that the the_silver_searcher is being packaged for Fedora
> right now, we could temporarily have Ag as the name for it in Fedora,
> and define an alias in /etc/profile.d/ag.*sh (as which does).
> It's OK for me the python-ase ag name is overwritten by the_silver_searcher
> for these couple of months, as long as we use this bug to document what
> happens.

That would move the conflict in my opinion, wouldn't it ? If by any chance someone  installed both the_silver_searcher and python-ase, they would get only the_silver_searcher on the command line for both ag and Ag, isn't that bad ?

We would just shift the conflict in a less obvious way. I'd rather go for a firm conflict during installation.

> After the (hopefully already) next python-ase release the only remaining
> thing 
> to be done will be to restore the ag name and remove /etc/profile.d/ag.*sh,
> and close this bug as resolved.

Sounds like a breaking change to me, it'd have to happen between two releases of Fedora, wouldn't it ? This applies for both Ag=>ag and ag=>ase-gui, does it?

(In reply to Dridi Boukelmoune from comment #2)
> Thank you for your feedback, this very helpful :)
> 
> (In reply to marcindulak from comment #1)
> > python-ase has a branch
> > (https://svn.fysik.dtu.dk/projects/ase/branches/cli/tools/) which uses
> > ase-gui instead of ag, but it may be at least several months before it gets
> > merged to the trunk and a new release of python-ase made.
> 
> This is great news, could we get in touch with upstream to ask how much time
> it should take before it's merged and released ? (an estimation)

it's already merged, but the current trunk state does not qualify for release.
We don't have planned release schedule, but we have the ag/ase-gui conflict in mind while working. Maybe in a couple of weeks (instead of months)
we may have a new python-ase release.

> 
> > Note that python-ase' ag is not simply a gui starter - it accepts also
> > command
> > line arguments and can be used without any gui, e.g.:
> > https://wiki.fysik.dtu.dk/ase/ase/gui/basics.html#plotting-data-from-the-
> > command-line
> 
> This is unfortunate for the_silver_searcher, but this is interesting to know.
> 
> > The convention for atomic symbols is to capitalize the first letter
> > http://en.wikipedia.org/wiki/Chemical_symbol so the_silver_searcher could
> > in the first place use Ag instead of ag.
> > I see there are several packages that install executables
> > with capitalized names `LC_ALL=C ls /usr/bin/[[:upper:]]*`.
> 
> Yes but, my canonical example (mercurial) uses hg not because people didn't
> know mercury's symbol is Hg. Maybe they don't but I guess this is because
> lowercase hg is more user-friendly on the CLI.
> 
> > Due to the fact that the the_silver_searcher is being packaged for Fedora
> > right now, we could temporarily have Ag as the name for it in Fedora,
> > and define an alias in /etc/profile.d/ag.*sh (as which does).
> > It's OK for me the python-ase ag name is overwritten by the_silver_searcher
> > for these couple of months, as long as we use this bug to document what
> > happens.
> 
> That would move the conflict in my opinion, wouldn't it ? If by any chance
> someone  installed both the_silver_searcher and python-ase, they would get
> only the_silver_searcher on the command line for both ag and Ag, isn't that
> bad ?

yes, i suggested hiding the conflict by using /etc/profile.d,
in case you need to get the_silver_searcher package into official repositories
as soon as possible. The user base of python-ase and the_silver_searcher is rather different, so that would go unnoticed, and we have this bug open.

> 
> We would just shift the conflict in a less obvious way. I'd rather go for a
> firm conflict during installation.

OK, so let's have patience.

> 
> > After the (hopefully already) next python-ase release the only remaining
> > thing 
> > to be done will be to restore the ag name and remove /etc/profile.d/ag.*sh,
> > and close this bug as resolved.
> 
> Sounds like a breaking change to me, it'd have to happen between two
> releases of Fedora, wouldn't it ? This applies for both Ag=>ag and
> ag=>ase-gui, does it?

python-ase-3.8.1.3440-7.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-7.fc19

python-ase-3.8.1.3440-7.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-7.el6

python-ase-3.8.1.3440-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-7.fc20

python-ase-3.8.1.3440-7.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-7.el5

python-ase-3.8.1.3440-7.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-7.fc18

Package python-ase-3.8.1.3440-7.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-ase-3.8.1.3440-7.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-22286/python-ase-3.8.1.3440-7.fc20
then log in and leave karma (feedback).

I'm giving you negative karma, because of small issues in the package. Overall, this update made my week and I was dying to review it :D

Issues:
* the desktop file for ase-gui contains Exec=ag
* build logs and the manifest don't belong in %{_pkgdocdir}, do they ?

As I said, small issues!

python-ase-3.8.1.3440-8.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-8.fc20

python-ase-3.8.1.3440-8.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-8.fc18

python-ase-3.8.1.3440-8.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-8.el6

python-ase-3.8.1.3440-8.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-8.fc19

(In reply to Dridi Boukelmoune from comment #10)
> I'm giving you negative karma, because of small issues in the package.
> Overall, this update made my week and I was dying to review it :D
> 
> Issues:
> * the desktop file for ase-gui contains Exec=ag

fixed now

> * build logs and the manifest don't belong in %{_pkgdocdir}, do they ?

i prefer to keep the build logs there, especially p2testase.log.
MANIFEST.in removed

> 
> As I said, small issues!

no more el5 package. python-ase requires now python >= 2.6

python-ase-3.8.1.3440-9.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-9.fc18

python-ase-3.8.1.3440-9.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-9.fc19

python-ase-3.8.1.3440-9.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-9.el6

python-ase-3.8.1.3440-9.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-9.fc20

(In reply to marcindulak from comment #15)
> no more el5 package. python-ase requires now python >= 2.6

There is some python26 package in el5 to make a small Python 2.6 stack available.  You will just need some small adaptions in your spec-file to get it working  ;)  A python27 package is in preperation for el5 && el6, if there will be some future updates on ase, which will need Python >= 2.7

(In reply to Björn "besser82" Esser from comment #20)
> (In reply to marcindulak from comment #15)
> > no more el5 package. python-ase requires now python >= 2.6
> 
> There is some python26 package in el5 to make a small Python 2.6 stack
> available.  You will just need some small adaptions in your spec-file to get
> it working  ;)  A python27 package is in preperation for el5 && el6, if
> there will be some future updates on ase, which will need Python >= 2.7

i see there is even python26-numpy available, but python-ase in order to be fully functional (GUI) would need also python26-matplotlib, and even worse pygtk2 that may be possibly called python26-pygtk2, python26-gtk2 or py26gtk2 (?).
Are there plans to package also those?

python-ase-3.8.1.3440-10.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-10.fc19

python-ase-3.8.1.3440-10.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-10.el6

python-ase-3.8.1.3440-10.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/python-ase-3.8.1.3440-10.fc20

python-ase-3.8.1.3440-10.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

python-ase-3.8.1.3440-10.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

python-ase-3.8.1.3440-10.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.