[RtM] Added py-proj/package.py (RtM = Ready to Merge) #717

citibeth · 2016-04-01T20:05:14Z

No description provided.

mathstuf · 2016-04-05T15:17:03Z

var/spack/repos/builtin/packages/py-proj/package.py

+    extends('python')
+
+    depends_on('py-cython')
+    depends_on('py-setuptools')


This doesn't depends_on the proj library?

GitHub formatted the PR in a funny way. But at the end of the file in the
PR (not quoted above), there's a note explaining this:

+ # The py-proj git repo actually includes the correct version of PROJ.4, + # which is built internally as part of the py-proj build. + # Adding depends_on('proj') will cause mysterious build errors. + + def install(self, spec, prefix): + python('setup.py', 'install', '--prefix=%s' % prefix)

-- Elizabeth

On Tue, Apr 5, 2016 at 11:17 AM, Ben Boeckel notifications@github.com
wrote:

In var/spack/repos/builtin/packages/py-proj/package.py:

homepage = "http://jswhit.github.io/pyproj/"

url = "https://github.com/jswhit/pyproj/tarball/v1.9.5.1rel"

version('1.9.5.1', 'a4b80d7170fc82aee363d7f980279835')

We need the benefits of this PR

Change Proj.to_latlong in order to return an instance of pyproj.Proj pyproj4/pyproj#54

version('citibeth-latlong2',

git='https://github.com/citibeth/pyproj.git',

branch='latlong2')

extends('python')

depends_on('py-cython')

depends_on('py-setuptools')

This doesn't depends_on the proj library?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/LLNL/spack/pull/717/files/552a2815cd82b04c74eac44352f5e812ea0fa7f6#r58556930

Not using the proj that others are using is going to be a problem as well. There's this libproj4 with the symbol pj_free. A project using proj4's actual library also uses Python (ParaView is not farfetched for this) and that code loads the proj Python module. What proj library is used? If it is the one built by spack for ParaView, the Python might not match that one. ParaView can't use the one packaged here (it can't know about it), but if the soname doesn't match, you get duplicate symbols.

This really needs to use an external proj4.

@citibeth: I think it's bad if using py-proj and proj at the same time fails... maybe @mathstuf can look into this if he's got time. @mathstuf: have you used an external proj?

@tgamblin: I agree on the code sharing. But I don't think there's much to
be done here, short of significant rewrites of py-proj. If there had
been an obvious way to depend on an external proj, I would have done it.

I'm also not comfortable putting a git version in the Spack dev branch,
because it is not checksummed. The problem is, the release version of
py-proj has a small-to-fix, but show-stopping bug (for my application).
Some PR's were submitted, but remain unmerged. Unfortunately, the branch
in my fork is still the only one that works (for me).

https://github.com/jswhit/pyproj/pull/73

I can see the following ways forward:

Hold this PR until upstream is fixed. The problem with that is, someone
else who needs py-proj might waste their effort re-writing this Spack
package.

Remove the citibeth-latlong2 version from the PR that gets merged into
dev, and hope that other Spack users don't need it (they probably won't
unless they use Python3).

Create a tagged release of citibeth-latlong2 on my fork, and add that
version to Spack, with hashcode.

I'm thinking (3) is probably the way forward.

Your thoughts?
-- Elizabeth

On Tue, May 10, 2016 at 4:39 AM, Todd Gamblin notifications@github.com
wrote:

In var/spack/repos/builtin/packages/py-proj/package.py:

homepage = "http://jswhit.github.io/pyproj/"

url = "https://github.com/jswhit/pyproj/tarball/v1.9.5.1rel"

version('1.9.5.1', 'a4b80d7170fc82aee363d7f980279835')

We need the benefits of this PR

Change Proj.to_latlong in order to return an instance of pyproj.Proj pyproj4/pyproj#54

version('citibeth-latlong2',

git='https://github.com/citibeth/pyproj.git',

branch='latlong2')

extends('python')

depends_on('py-cython')

depends_on('py-setuptools')

@citibeth https://github.com/citibeth: I think it's bad if using py-proj
and proj at the same time fails... maybe @mathstuf
https://github.com/mathstuf can look into this if he's got time.
@mathstuf https://github.com/mathstuf: have you used an external proj?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/LLNL/spack/pull/717/files/552a2815cd82b04c74eac44352f5e812ea0fa7f6#r62631624

Huh?
On May 31, 2016 11:14 AM, "Ben Boeckel" notifications@github.com wrote:

In var/spack/repos/builtin/packages/py-proj/package.py:

homepage = "http://jswhit.github.io/pyproj/"

url = "https://github.com/jswhit/pyproj/tarball/v1.9.5.1rel"

version('1.9.5.1', 'a4b80d7170fc82aee363d7f980279835')

We need the benefits of this PR

Change Proj.to_latlong in order to return an instance of pyproj.Proj pyproj4/pyproj#54

version('citibeth-latlong2',

git='https://github.com/citibeth/pyproj.git',

branch='latlong2')

extends('python')

depends_on('py-cython')

depends_on('py-setuptools')

@mathstuf https://github.com/mathstuf: have you used an external proj?

Never used py-proj myself (I'm more familiar with proj4, but that's
really just "it's in our build stack and I'm one of the build stack guys"
kind of relationship); just pointing out that mixing multiple libraries
with the same symbols tends to not go too well…

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/LLNL/spack/pull/717/files/552a2815cd82b04c74eac44352f5e812ea0fa7f6#r65201976,
or mute the thread
https://github.com/notifications/unsubscribe/AB1cd6AWPD01dI1JJSI3dq3c30cvNkq4ks5qHFA-gaJpZM4H9_nz
.

So is this one still WIP?

marked it WIP -- feel free to unmark when ready...

py-setuptools is probably a build dependency? Not sure about py-cython.

I agree. But a grep through the repo reveals some confusion over
type='build' vs. type=nolink. My guess is type=build is right, and
type=nolink needs to be converted. Your opinions?

I'll fix the packages below that are mine (glint2, ibmisc, icebin, py-proj).

cantera/package.py: depends_on('py-cython', when='+python', type=nolink) glint2/package.py: depends_on('py-cython', when='+python') ibmisc/package.py: depends_on('py-cython', when='+python', type=nolink) icebin/package.py: depends_on('py-cython', when='+python') py-h5py/package.py: depends_on('py-cython@0.19:', type='build') py-iminuit/package.py: depends_on('py-cython', type='build') py-netcdf/package.py: depends_on('py-cython', type=nolink) py-proj/package.py: depends_on('py-cython') py-pytables/package.py: depends_on('py-cython', type=nolink)

On Fri, Sep 2, 2016 at 9:26 AM, Adam J. Stewart notifications@github.com
wrote:

In var/spack/repos/builtin/packages/py-proj/package.py:

homepage = "http://jswhit.github.io/pyproj/"

url = "https://github.com/jswhit/pyproj/tarball/v1.9.5.1rel"

version('1.9.5.1', 'a4b80d7170fc82aee363d7f980279835')

We need the benefits of this PR

Change Proj.to_latlong in order to return an instance of pyproj.Proj pyproj4/pyproj#54

version('citibeth-latlong2',

git='https://github.com/citibeth/pyproj.git',

branch='latlong2')

extends('python')

depends_on('py-cython')

depends_on('py-setuptools')

py-setuptools is probably a build dependency? Not sure about py-cython.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/LLNL/spack/pull/717/files/552a2815cd82b04c74eac44352f5e812ea0fa7f6#r77345291,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB1cd69ohdDBe-Im4zrFwehp40mIpyubks5qmCQOgaJpZM4H9_nz
.

…ixes have been merged into the main repo.

Added a blank line that Travis wanted.

citibeth · 2016-08-17T04:12:56Z

@tgamblin This is ready to merge.

citibeth · 2016-09-02T02:28:50Z

@tgamblin ping, can this please get merged? I believe all discussion has been resolved.

adamjstewart · 2016-09-02T13:25:49Z

var/spack/repos/builtin/packages/py-proj/package.py

@@ -0,0 +1,27 @@
+from spack import *


Missing licensing info above.

Is this a problem? I find tons of packages with missing license info.

On Fri, Sep 2, 2016 at 9:25 AM, Adam J. Stewart notifications@github.com
wrote:

In var/spack/repos/builtin/packages/py-proj/package.py:

@@ -0,0 +1,27 @@
+from spack import *

Missing licensing info above.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/LLNL/spack/pull/717/files/15797aace19e798d7a7cf80e7e3e345687672414#r77345182,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB1cdw86zpWnQEg3R35UVDGdNMwDsChWks5qmCPfgaJpZM4H9_nz
.

2. Used setup_py 3. Added type='build' for dependencies.

citibeth · 2016-09-02T23:30:12Z

Should be ready to merge now.

Elizabeth F and others added 4 commits April 1, 2016 15:25

Added py-proj package

905c240

Added bug-fix patched version to the package.

dc6dc06

Removed dependency of py-proj on proj.

94dffd3

py-proj: Added missing dependency

552a281

mathstuf reviewed Apr 5, 2016
View reviewed changes

Elizabeth Fischer and others added 2 commits May 14, 2016 16:09

py-proj: Removed versions from forked repos, now that necessary bug f…

eab87aa

…ixes have been merged into the main repo.

Update package.py

15797aa

Added a blank line that Travis wanted.

tgamblin changed the title ~~Added py-proj/package.py~~ [WIP] Added py-proj/package.py Jun 2, 2016

citibeth changed the title ~~[WIP] Added py-proj/package.py~~ [RtM] Added py-proj/package.py (RtM = Ready to Merge) Jun 5, 2016

adamjstewart reviewed Sep 2, 2016
View reviewed changes

1. Added copyright

9021d3c

2. Used setup_py 3. Added type='build' for dependencies.

tgamblin merged commit 2a823fb into spack:develop Sep 15, 2016

citibeth deleted the efischer/160401-PyProj branch October 6, 2016 14:15

matz-e pushed a commit to matz-e/spack that referenced this pull request Apr 27, 2020

update license year of py-neuron-reduce (spack#717)

6266926

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[RtM] Added py-proj/package.py (RtM = Ready to Merge) #717

[RtM] Added py-proj/package.py (RtM = Ready to Merge) #717

citibeth commented Apr 1, 2016

mathstuf Apr 5, 2016

citibeth Apr 5, 2016

We need the benefits of this PR

Change Proj.to_latlong in order to return an instance of pyproj.Proj pyproj4/pyproj#54

mathstuf Apr 5, 2016

tgamblin May 10, 2016

citibeth May 10, 2016

We need the benefits of this PR

Change Proj.to_latlong in order to return an instance of pyproj.Proj pyproj4/pyproj#54

citibeth May 31, 2016

We need the benefits of this PR

Change Proj.to_latlong in order to return an instance of pyproj.Proj pyproj4/pyproj#54

tgamblin Jun 2, 2016

tgamblin Jun 2, 2016

adamjstewart Sep 2, 2016

citibeth Sep 2, 2016

We need the benefits of this PR

Change Proj.to_latlong in order to return an instance of pyproj.Proj pyproj4/pyproj#54

citibeth commented Aug 17, 2016

citibeth commented Sep 2, 2016

adamjstewart Sep 2, 2016

citibeth Sep 2, 2016

citibeth commented Sep 2, 2016

[RtM] Added py-proj/package.py (RtM = Ready to Merge) #717

[RtM] Added py-proj/package.py (RtM = Ready to Merge) #717

Conversation

citibeth commented Apr 1, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

We need the benefits of this PR

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

We need the benefits of this PR

Choose a reason for hiding this comment

We need the benefits of this PR

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

We need the benefits of this PR

citibeth commented Aug 17, 2016

citibeth commented Sep 2, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

citibeth commented Sep 2, 2016