astroconda / astroconda-contrib Goto Github PK

Community Submitted Conda Recipes

Batchfile 26.79% Shell 72.99% Python 0.22%

astroconda-contrib's Introduction

STScI will end support for astroconda on February 1st, 2023

Warning

Astroconda is no longer supported by STScI; support ended on February 1st, 2023. Users are encouraged to use stenv stenv provides a common environment for both the Hubble Space Telescope (HST) and the James Webb Space Telescope (JWST) pipelines and includes most commonly-used packages in Astroconda. Questions about this transition can be directed to the HST Help Desk: hsthelp.stsci.edu

Full Astroconda documentation

astroconda-contrib's People

Contributors

Stargazers

Watchers

astroconda-contrib's Issues

Need to include bug fix release of photutils 0.3 here

Need to include bug fix release of photutils 0.3 here so that workshop PSF notebook would work properly. c/c @eteq

astroconda still installs glueviz 0.9.0 not 0.9.1

c/c @astrofrog

Installing astroconda broke my TensorFlow related code

Hi there,
I use the Keras neural networks library (https://keras.io/) that is based on Theano and TensorFlow.

I installed astroconda earlier today, and this broke my Python-Keras code, since I can't now use/import TensorFlow. I've tracked down this directory:
/Users/npr1/astroconda/lib/python3.5/site-packages/keras/backend
but really don't know what to do next.

Little help??!
Thanks,
Nic
[email protected]

Astroquery now has rolling release

Not sure how/if you want to incorporate this into astroconda channel.

See astropy/astroquery#1156 for installation doc update.

Missing libssl.so.10 for ds9

I installed the Anaconda3 on Ubuntu-18.04 (64-bit). I ran the following command to set-up iraf environment:
$ conda create -n iraf27 python=2.7 iraf-all pyraf-all stsci
When I starts IRAF and try to open ds9, it says:
ecl> !ds9
ds9: error while loading shared libraries: libssl.so.10: cannot open shared object file: No such file or directory
ecl>

I checked the library file is present using the command:
$ sudo find / -name libssl.so.10
/lib/x86_64-linux-gnu/libssl.so.10
I don't know why still it is not working. Please help me for the same.

Thanks..

ds9 v7.5 crashes when sent a 544x4224 array by numdisplay

This prevents displaying GMOS data using some of our scripts under Astroconda (with numdisplay v1.6.1.dev).

d=np.zeros(shape=(4224, 544), dtype=np.uint16)   # dtype doesn't actually matter
numdisplay.display(d)

It also happens with SAO's binaries (v 7.5 for CentOS 6 and v7.4 for "Linux") so it's not an Astroconda specific problem and it happens with numdisplay 1.6 in Ureka but not when using Ureka's old ds9 v7.1 (or reverting to v7.1 in Astroconda). So this seems to be a problem in recent ds9 versions that I should probably report upstream, but I'm noting it here so we can keep track of it.

In the meantime, this is resolved by conda install ds9=7.1.

Error running conda build check for pysiaf

I just updated the pysiaf package to v0.6.1 and in trying to update it in astroconda-contrib, I updated the meta.yaml flie with the new version # and one new package requirement, and then ran the line conda build -c http://ssb.stsci.edu/astroconda --skip-existing --python=3.5 pysiaf as a check. It failed for python 3.5, finding tons of conflicts during the Attempting to finalize metadata for pysiaf section, but passed when I set it to python 3.6.

Does astroconda-contrib require that packages pass in python 3.5 to be included (since that's the version used in the ReadtheDocs example)? Also, all our dependencies seem to be 3.5 compatible, but does this build process failing indicate that the package as a whole is somehow no longer python 3.5 compatible? (I'm not sure exactly what is happening within this build command)

tagging @Johannes-Sahlmann

Remove "decorator" from channel

It is provided by defaults and should not be in this channel, or the dev channel.

This package has an impact on old/new pipeline specs, so we need to make this change with care.

Ref: #45

MNT: Clean ci-watson recipe when we can

Revert 8a10a62 when Anaconda lets us. cc @rendinam

p.s. Opening an issue so we don't forget.

`conda install jwst_coronagraph_visibility` installs version 0.1.0, not the latest version 0.4.2

Version 0.4.2 can be installed with conda install jwst_coronagraph_visibility=0.4.2, however it would be best if the latest version can be installed with conda install jwst_coronagraph_visibility.

Problem after adding astroconda channel

We had an issue submitted in the webbpsf repository by @PatrickOgle about an issue he had when trying add the astroconda channel as part of installing webbpsf.

WebbPSF uses the same installation instructions for astroconda as the astroconda docs, which is conda config --add channels http://ssb.stsci.edu/astroconda (found here https://astroconda.readthedocs.io/en/latest/installation.html). But Patrick says that after he added the astroconda channel this way, he was unable to create any new conda environments. You can see the full description of the problem here: spacetelescope/webbpsf#379

Since this seems more like a conda/astroconda issue, I wanted to reach out and see if you had seen this kind of behavior before with astroconda?

ModuleNotFoundError

Hi - I am getting this error -
ModuleNotFoundError: No module named 'stsci.tools'

But, the module is in my path and i have also tried updating all. Its still showing the error. Please let me know what to do.

Uninstalling pysynphot also uninstalls astroquery for no reason

How is this even possible?

$ conda uninstall pysynphot
Fetching package metadata .................
Solving package specifications: .

Package plan for package removal in environment .../anaconda/envs/dadf:

The following packages will be REMOVED:

    astroquery: 0.3.6.post2-py35_2 astropy                        
    pysynphot:  0.9.8.7-py35_0     http://ssb.stsci.edu/astroconda

pyds9 version in the astroconda channel appears to be wrong

Hi.

I made a fresh installation of astroconda (with python=3.7). I intended to use the pyds9 package and I was getting import errors because the six package was not installed.
The version in astroconda is listed as 1.9.0.dev145+gc1bf67a, which should include the changes that remove the six dependencies (along with python 2.7). Looking at the code though, the six dependency is still there. Is astroconda not picking up the correct version of the code? I was comparing the astroconda version of the code with the one found here: https://github.com/ericmandel/pyds9

stsci metapackage has Astropy conflict between calcos and glue

From a help call

User needs to downgrade Astropy for calcos to run but is prevented from doing so by Glue.

$ conda create -n cos python=3 stsci
$ source activate cos
$ conda install astropy=1.2.1
Fetching package metadata ...........
Solving package specifications: .
 UnsatisfiableError: The following specifications were found to be in conflict:
   - astropy 1.2.1*
   - glue-core -> astropy >=1.3 -> numpy 1.12*
 Use "conda info <package>" to see the dependencies for each package.

IRAF help for noao tasks missing in astroconda?

Hi,

I have a user reporting that when she tries to get help for tasks in the noao package, she obtains the following error message (example for "standard" task):

help standard:
cannot open help database file noao$lib/helpdb.mip
No help available for 'standard'

Indeed the directory iraf/noao/lib/ inside astroconda seems to be missing the helpdb.mip file, which is present in my own (pre-astroconda) IRAF 2.16.1 installation.

Just to be sure I downloaded file http://ssb.stsci.edu/astroconda/osx-64/iraf-2.16.1-0.tar.bz2, and noao's helpdb.mip file is not there either.

Thanks!

Nicola

Consider auditing recipes and remove unmaintained packages

The use case that brought this up was cube-tools, which has not been updated for a year, causing conflicts with other package updates (e.g., astropy). cube-tools was a result of JWST DADF sprints and has not been maintained much since then.

We should not be polluting AstroConda channel with "dead" or experimental packages. Some kind of auditing needs to be put in place to keep this environment clean.

c/c @saraogaz @rendinam @jhunkeler

stsci.skypac: Invalid tag?

Recipe version definition here:
https://github.com/astroconda/astroconda-contrib/blob/master/stsci.skypac/meta.yaml#L1-L3
"0.9.15"

And from the build system(s):

Cloning into '/Users/iraf/build/pembry/workspace/AstroConda/public_OSX-10.11_py3.6_np1.11/_dispatch/miniconda/conda-bld/stsci.skypac_1533542508680/work'...
done.
checkout: '0.9.15'
error: pathspec '0.9.15' did not match any file(s) known to git.
Warning: failed to download source.  If building, will try again after downloading recipe dependencies.
Error was: 
Command '['/usr/bin/git', 'checkout', '0.9.15']' returned non-zero exit status 1.
Failed to download or patch source. Please see build log for info.

0.9.14 exists, so what's up?

cc @mcara

[conda] Python 3.7.4 package is broken

The failure below is specific to conda's Python 3.7.4 package. This issue does not appear when using a Python interpreter just-compiled from source.

Temporary solution(s):

$ conda install python=3.7.3
# and
$ conda build --python=3.7.3 [...]

Sample:

building 'calcos.ccos' extension
creating build/temp.linux-x86_64-3.7
creating build/temp.linux-x86_64-3.7/src
gcc -pthread -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DNUMPY=1 -I/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/conda-bld/calcos_1565724069928/_h_env_placeh/lib/python3.7/site-packages/numpy/core/include -I/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/conda-bld/calcos_1565724069928/_h_env_placeh/include/python3.7m -c src/ccos.c -o build/temp.linux-x86_64-3.7/src/ccos.o
In file included from /srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/conda-bld/calcos_1565724069928/_h_env_placeh/lib/python3.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1824,
                 from /srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/conda-bld/calcos_1565724069928/_h_env_placeh/lib/python3.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:12,
                 from /srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/conda-bld/calcos_1565724069928/_h_env_placeh/lib/python3.7/site-packages/numpy/core/include/numpy/arrayobject.h:4,
                 from src/ccos.c:119:
/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/conda-bld/calcos_1565724069928/_h_env_placeh/lib/python3.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: warning: #warning "Using deprecated NumPy API, disable it with " "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
src/ccos.c: In function ‘ccos_pha_check’:
src/ccos.c:2406: warning: ‘nlow’ may be used uninitialized in this function
src/ccos.c:2406: warning: ‘nhigh’ may be used uninitialized in this function
gcc -pthread -shared -L/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/conda-bld/calcos_1565724069928/_h_env_placeh/lib -Wl,-rpath=/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/conda-bld/calcos_1565724069928/_h_env_placeh/lib -Wl,--no-as-needed -Wl,--sysroot=/ build/temp.linux-x86_64-3.7/src/ccos.o -o build/lib.linux-x86_64-3.7/calcos/ccos.cpython-@PYVERNODOTS@m-x86_64-linux-gnu.so
/usr/bin/ld: this linker was not configured to use sysroots
collect2: ld returned 1 exit status
/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/conda-bld/calcos_1565724069928/_h_env_placeh/lib/python3.7/site-packages/setuptools/dist.py:45: DistDeprecationWarning: Do not call this function
  warnings.warn("Do not call this function", DistDeprecationWarning)
error: command 'gcc' failed with exit status 1
Traceback (most recent call last):
  File "/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/bin/conda-build", line 11, in <module>
    sys.exit(main())
  File "/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/lib/python3.7/site-packages/conda_build/cli/main_build.py", line 424, in main
    execute(sys.argv[1:])
  File "/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/lib/python3.7/site-packages/conda_build/cli/main_build.py", line 415, in execute
    verify=args.verify)
  File "/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/lib/python3.7/site-packages/conda_build/api.py", line 200, in build
    notest=notest, need_source_download=need_source_download, variants=variants)
  File "/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/lib/python3.7/site-packages/conda_build/build.py", line 2206, in build_tree
    notest=notest,
  File "/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/lib/python3.7/site-packages/conda_build/build.py", line 1446, in build
    utils.check_call_env(cmd, env=env, cwd=src_dir, stats=build_stats)
  File "/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/lib/python3.7/site-packages/conda_build/utils.py", line 310, in check_call_env
    return _func_defaulting_env_to_os_environ('call', *popenargs, **kwargs)
  File "/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/lib/python3.7/site-packages/conda_build/utils.py", line 290, in _func_defaulting_env_to_os_environ
    raise subprocess.CalledProcessError(proc.returncode, _args)
subprocess.CalledProcessError: Command '['/bin/bash', '-e', '/srv/jenkins/workspace/AstroConda/public_RHEL-6_py3.7_np1.16/_dispatch/miniconda/conda-bld/calcos_1565724069928/work/conda_build.sh']' returned non-zero exit status 1.

synphot iraf crash, linux mint

iraf and all packages intalled from astroconda, downloaded all synphot-data files, $PYSYN_CDBS path added in bash_profile and crrefer in login.cl
iraf and pyraf works fine, but calcphot always crashes. Example

synphot> calcphot "band(wfpc,f555w)" "rn(bb(5000),band(v),18.6,vegamag)" counts

*** Error in `/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e': free(): invalid next size (fast): 0x0aba7f90 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x67377)[0x55751377]
/lib/i386-linux-gnu/libc.so.6(+0x6d2f7)[0x557572f7]
/lib/i386-linux-gnu/libc.so.6(+0x6dc31)[0x55757c31]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x809b814]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x808b4c7]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x8088832]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x80809a7]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x8078740]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x808294f]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x807d50c]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x807de7e]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x807e83e]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x80636a9]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x80502b0]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x804d5f3]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x815124b]
/home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin/x_synphot.e[0x80ae8a5]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0x55702637]
======= Memory map: ========
08048000-08395000 r-xp 00000000 08:15 1769463 /home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin.linux/x_synphot.e
08395000-083b8000 rwxp 0034d000 08:15 1769463 /home/qssha/miniconda2/envs/iraf27/iraf_extern/stsdas/bin.linux/x_synphot.e
083b8000-0a97c000 rwxp 00000000 00:00 0
0ab40000-0abbc000 rwxp 00000000 00:00 0 [heap]
55614000-55636000 r-xp 00000000 08:15 4980778 /lib/i386-linux-gnu/ld-2.23.so
55636000-55637000 rwxp 00000000 00:00 0
55637000-55638000 r-xp 00022000 08:15 4980778 /lib/i386-linux-gnu/ld-2.23.so
55638000-55639000 rwxp 00023000 08:15 4980778 /lib/i386-linux-gnu/ld-2.23.so
55639000-5563b000 r--p 00000000 00:00 0 [vvar]
5563b000-5563c000 r-xp 00000000 00:00 0 [vdso]
5563c000-55660000 rwxp 00000000 00:00 0
55660000-55668000 r-xp 00000000 08:15 4985888 /lib/i386-linux-gnu/libnss_compat-2.23.so
55668000-55669000 r-xp 00007000 08:15 4985888 /lib/i386-linux-gnu/libnss_compat-2.23.so
55669000-5566a000 rwxp 00008000 08:15 4985888 /lib/i386-linux-gnu/libnss_compat-2.23.so
5566a000-5566b000 rwxp 00000000 00:00 0
5566f000-556c2000 r-xp 00000000 08:15 4985896 /lib/i386-linux-gnu/libm-2.23.so
556c2000-556c3000 r-xp 00052000 08:15 4985896 /lib/i386-linux-gnu/libm-2.23.so
556c3000-556c4000 rwxp 00053000 08:15 4985896 /lib/i386-linux-gnu/libm-2.23.so
556c4000-556dd000 r-xp 00000000 08:15 4980920 /lib/i386-linux-gnu/libpthread-2.23.so
556dd000-556de000 r-xp 00018000 08:15 4980920 /lib/i386-linux-gnu/libpthread-2.23.so
556de000-556df000 rwxp 00019000 08:15 4980920 /lib/i386-linux-gnu/libpthread-2.23.so
556df000-556e1000 rwxp 00000000 00:00 0
556e1000-556e8000 r-xp 00000000 08:15 4985875 /lib/i386-linux-gnu/librt-2.23.so
556e8000-556e9000 r-xp 00006000 08:15 4985875 /lib/i386-linux-gnu/librt-2.23.so
556e9000-556ea000 rwxp 00007000 08:15 4985875 /lib/i386-linux-gnu/librt-2.23.so
556ea000-5589a000 r-xp 00000000 08:15 4985903 /lib/i386-linux-gnu/libc-2.23.so
5589a000-5589c000 r-xp 001af000 08:15 4985903 /lib/i386-linux-gnu/libc-2.23.so
5589c000-5589d000 rwxp 001b1000 08:15 4985903 /lib/i386-linux-gnu/libc-2.23.so
5589d000-558a1000 rwxp 00000000 00:00 0
558a1000-558ac000 r-xp 00000000 08:15 4980782 /lib/i386-linux-gnu/libnss_files-2.23.so
558ac000-558ad000 r-xp 0000a000 08:15 4980782 /lib/i386-linux-gnu/libnss_files-2.23.so
558ad000-558ae000 rwxp 0000b000 08:15 4980782 /lib/i386-linux-gnu/libnss_files-2.23.so
558ae000-55911000 rwxp 00000000 00:00 0
55942000-55959000 r-xp 00000000 08:15 4980773 /lib/i386-linux-gnu/libnsl-2.23.so
55959000-5595a000 r-xp 00016000 08:15 4980773 /lib/i386-linux-gnu/libnsl-2.23.so
5595a000-5595b000 rwxp 00017000 08:15 4980773 /lib/i386-linux-gnu/libnsl-2.23.so
5595b000-5595d000 rwxp 00000000 00:00 0
5595d000-55968000 r-xp 00000000 08:15 4982075 /lib/i386-linux-gnu/libnss_nis-2.23.so
55968000-55969000 r-xp 0000a000 08:15 4982075 /lib/i386-linux-gnu/libnss_nis-2.23.so
55969000-5596a000 rwxp 0000b000 08:15 4982075 /lib/i386-linux-gnu/libnss_nis-2.23.so
5596a000-55986000 r-xp 00000000 08:15 4982077 /lib/i386-linux-gnu/libgcc_s.so.1
55986000-55987000 rwxp 0001b000 08:15 4982077 /lib/i386-linux-gnu/libgcc_s.so.1
55a00000-55a21000 rwxp 00000000 00:00 0
55a21000-55b00000 ---p 00000000 00:00 0
fff70000-fff91000 rwxp 00000000 00:00 0 [stack]
ERROR: abort

How i can fix this?

glue-vispy-viewers needs PyOpenGL

@astrofrog FYI

===== testing package: glue-vispy-viewers-0.7.1-0 =====
import: 'glue_vispy_viewers'
Traceback (most recent call last):
  File "/Users/shared/iraf_conda/bldtmp/porcelain.pmVJ2MUA7O/porcelain/conda-bld/glue-vispy-viewers_1487581349474/test_tmp/run_test.py", line 27, in <module>
    import glue_vispy_viewers
  File "/Users/shared/iraf_conda/bldtmp/porcelain.pmVJ2MUA7O/porcelain/conda-bld/glue-vispy-viewers_1487581349474/_t_env/lib/python2.7/site-packages/glue_vispy_viewers/__init__.py", line 9, in <module>
    raise ImportError("The PyOpenGL package is required for this plugin")
ImportError: The PyOpenGL package is required for this plugin

Add astroquery to stsci metapackage

astroquery should be included when people do conda create -n astroconda stsci as instructed in http://astroconda.readthedocs.io/en/latest/installation.html#standard-install .

@tddesjardins @rayalucas

Where can I set PYTHONPATH from?

Hi,
when I first moved to python and in particular, anaconda (and astroconda) I learned that I could add a myenv.sh file in the directory:

anaconda3/envs/astroconda/etc/conda/activate.d/

that gets sourced when I do

source activate astroconda

This file allows me to add my own packages to that particular environment.
However when I recently installed astroconda on a new machine, I realized that the activate.d directory is no longer created.
I understand this is a choice related to the choice of not installing the webbpsf packeg by default, given its size, but still I do not understand why the activate.d directory itself should no longer be there.

The anaconda3/bin/activate script still looks for it, so why remove it?
If there is a good reason for removing it, could you please provide explanations on how one could
have access to one's own packages within the astroconda environment (i.e. how do I set pythonpath at startup for the astroconda environment only?)

Thanks,
Mario

Update the help

Tyler Desjardins mentions that we should consider moving emails from help[at]stsci.edu to point to the web portal where possible and appropriate. For HST (or any non-JWST), it is https://hsthelp.stsci.edu . For JWST, it is https://jwsthelp.stsci.edu . Please update info in setup.py, setup.cfg, documentation, etc as appropriate.

Please close this issue if it is irrelevant to your repository. This is an automated issue. If this is opened in error, please let pllim know!

xref spacetelescope/hstcal#317

Update CRDS release to 7.1.0, JWST build 7.1 development

This is also verified as solving the HST bug related to syncing required references with crds.bestrefs:

python -m crds.bestrefs --sync-references=1

Confusion between spherical-geometry and sphere

https://github.com/spacetelescope/sphere has actual package name of spherical_geometry. However, "astroconda" channel can only find it if I type "sphere", while "astropy" channel knows it as "spherical-geometry". It gets very confusing when I have both channels in my conda configuration. Which one is the correct name?

c/c @bernie-simon

Build packages for python 3.8 and 3.9

Currently all the conda packages here are only built for python<=3.7. Since 3.8 is out and useable, these packages should work under it as well.

Problem with ds9 7.6 on Mac OSX and non-RHEL-6 Linux

When installing the latest ds9 build on Mac OSX, the following error is encountered when trying to start ds9:

$ ds9
dyld: Library not loaded: /opt/local/lib/libxml2.2.dylib
Referenced from: /Users/scrawford/anaconda3/envs/test_ds9/bin/ds9
Reason: Incompatible library version: ds9 requires version 12.0.0 or later, but libxml2.2.dylib provides 
version 10.0.0
Abort trap: 6

Policy on PY3 only packages?

Does this channel accept packages that are no longer compatible with Python 2? If not, any plans to do so in the near future?

Update acstools

Update to latest bug fix release -- https://github.com/spacetelescope/acstools/releases/tag/2.0.2

fitsverify is broken with new cfitsio v3.430

I see that a new cfitsio build was put in the AstroConda channel on Friday. This appears to have broken the existing fitsverify package (reported by Ken), which probably requires a corresponding update of its own:

> fitsverify
fitsverify: error while loading shared libraries: libcfitsio.so.2: cannot open shared object file: No such file or directory

The new cfitsio package provides libcfitsio.so.5, rather than the libcfitsio.so.2 that the fitsverify binary is looking for. Thanks!

How packages make it into stsci metapackage?

@tddesjardins asked why some packages like synphot, stsynphot, and webbpsf don't get installed by default using conda create -n astroconda stsci.

jwst-visit-parser not available?

I recently asked to contribute jwst-visit-parser and #504 was merged. However the package does not seem to be available, see below. I am new to contributing packages and am wondering whether I have missed a step after #504 was merged?

Thank you.

conda install jwst-visit-parser

Collecting package metadata: done
Solving environment: failed

PackagesNotFoundError: The following packages are not available from current channels:

  - jwst-visit-parser

Current channels:

  - http://ssb.stsci.edu/astroconda/osx-64
  - http://ssb.stsci.edu/astroconda/noarch
  - https://repo.anaconda.com/pkgs/main/osx-64
  - https://repo.anaconda.com/pkgs/main/noarch
  - https://repo.anaconda.com/pkgs/free/osx-64
  - https://repo.anaconda.com/pkgs/free/noarch
  - https://repo.anaconda.com/pkgs/r/osx-64
  - https://repo.anaconda.com/pkgs/r/noarch
  - https://conda.anaconda.org/astropy/osx-64
  - https://conda.anaconda.org/astropy/noarch

To search for alternate channels that may provide the conda package you're
looking for, navigate to

    https://anaconda.org

and use the search bar at the top of the page.

Missing libXss for ds9

AstroConda's ds9 fails on a CentOS 7 machine because libXss.so.1 is not found. In Ureka, we included that library in Ureka/python/lib. AstroConda's ds9 build should probably just copy /usr/lib64/libXss.so.1 from the build machine into $PREFIX/lib on Linux (as for the 32-bit libs I'm copying to $PREFIX/lib32, for X11IRAF and ECL).

DS9 is also linked to other X11 libraries that we could bundle for portability, but in practice I believe libXss is the only one we have run into that is missing on some systems (in theory, I think libXau, libdmcp & libexpat are also not guaranteed to be present, whereas libX11, libXext, libXft, libXrender, libz, libfontconfig & libfreetype are part of the LSB and in some cases Anaconda too).

Installing notebook with astroconda

Hi,
I was wondering whether it would be possible to install the notebook package by default with astroconda.
I find it would be more practical than finding out that "jupyter notebook" doesn't work at first, and that notebook must be installed separately.

Thanks,
Mario

Cleanup stsci-data-analysis recipe

@jhunkeler the specview package isn't necessary anymore and should be removed. Is the general procedure for removing packages to remove the main recipe folder, and remove references to it from any meta-packages?

And then do the same to astroconda-dev?

wcstools 'scat' not in bin directory

The Ureka distribution used to have the wcstools catalog utility 'scat' included in the 'bin' so it could be used from the command line without having to do a second installation of wcstools. I find that useful because I have calls to that from my code. Perhaps there is now a way to do that using astropy, but it breaks backward compatibility for now. Is there a reason it was left out ?

Read time out downloading IRAF

I'm trying to install IRAF from astroconda and there keeps being timeout issues. I can install the rest of the conda packages as well as packages from astroconda, but it seems like the IRAF package is taking an extremely long time to download and then after 40 minutes it is timing out.

Update Ginga

It is best to update Ginga to the latest in master. Last commit there was June 9, 2016. Is this possible, @jhunkeler ?

p.s. It only works properly with Astropy 1.2 (or master or 1.2rc1).

Python 3.7 is out

Tried to upgrade to Python 3.7.0 and found a conflict here:

$ conda install python=3.7
Solving environment: failed

UnsatisfiableError: The following specifications were found to be in conflict:
  - pysiaf -> python[version='>=2.7,<2.8.0a0']
  - python=3.7
Use "conda info <package>" to see the dependencies for each package.

Not sure why it's showing the Python 2.7 constraints. I have pysiaf 0.1.8 py36_0 http://ssb.stsci.edu/astroconda installed per conda list.

Python not picking up stginga from this channel

I pulled Ginga and stginga from AstroConda channel but Python cannot find them in an interactive Python session. However, it picks up the command line scripts.

>>> import ginga  # From AstroConda channel
ImportError: No module named 'ginga'
>>> import stginga  # From AstroConda channel
ImportError: No module named 'stginga'
>>> import scipy  # From default Anaconda channel
>>> import astropy  # From default Anaconda channel
>>> astropy.__file__
'.../anaconda/envs/wssenv/lib/python3.5/site-packages/astropy/__init__.py'
>>> sys.path
['',
 '.../anaconda/envs/wssenv/lib/python35.zip',
 '.../anaconda/envs/wssenv/lib/python3.5',
 '.../anaconda/envs/wssenv/lib/python3.5/plat-linux',
 '.../anaconda/envs/wssenv/lib/python3.5/lib-dynload',
 '.../anaconda/envs/wssenv/lib/python3.5/site-packages/setuptools-23.0.0-py3.5.egg',
 '.../anaconda/envs/wssenv/lib/python3.5/site-packages']

> which python
.../anaconda/envs/wssenv/bin/python
> which ginga
.../anaconda/envs/wssenv/bin/ginga
> which stginga
.../anaconda/envs/wssenv/bin/stginga
> which fitsinfo  # Astropy
.../anaconda/envs/wssenv/bin/fitsinfo

Here are the contents inside installation directory:

> ls .../anaconda/envs/wssenv/lib/python3.5/site-packages/ | grep ginga
ginga-2.5.20160627100500-py3.5.egg/
stginga-0.1.1.dev192-py3.5.egg/
> ls .../anaconda/envs/wssenv/lib/python3.5/site-packages/ | grep astropy
astropy/
astropy-1.2.1-py3.5.egg-info/

This problem does not exist if I use pip or install from source.

Also, for Ginga, I force delete ../anaconda/pkgs/ginga* and then tried conda install ginga from AstroConda again, and this time I can import ginga. But the same trick does not work for stginga.

Set numpy minimum version

astropy>=4.2 requires numpy>=1.18 and the current build system only supports <=1.16

Read the docs, conda, and the SSB channel

For the JWST pipeline, an issue occurred when installing the documentation as part of the read the docs , see spacetelescope/jwst#2323

This issue was fixed by not including the SSB channel in the conda installation but installing most of the requirements from pip.

This may be due to the older version of conda being used in ReadTheDocs, but it would be good to understand what the underlying problem might be.

Need to implement windows support

Keeping this here just as a reminder.

Synphot 0.2.1 conda package does not play along well with pip

The conda package of synphot 0.2.0 worked well with pip. E.g.:

$ conda install "python >=3.7" "synphot =0.2.0"
$ pip install "synphot>0.1"

Requirement already satisfied: synphot>0.1 in [...]/lib/python3.8/site-packages (0.2.0)

However, 0.2.1 conda does not get along well with pip. E.g.:

$ conda install "python >=3.7" "synphot =0.2.1"
$ pip install "synphot>0.1"

[...]
Collecting synphot>0.1
Installing collected packages: synphot
  Found existing installation: synphot 0.0.0
    Uninstalling synphot-0.0.0:
      Successfully uninstalled synphot-0.0.0
Successfully installed synphot-0.2.1

In reality, this is triggered by me having one conda dependency that requires just synphot, and a pip dependency that requires "synphot>0.1". E.g.

conda install something_that_requires_synphot
pip install something_that_requires_synphot_gt_0_1

And in my case it will actually try to compile synphot 0.2.1 and fail because gcc is not installed on our CI image.

My guess is that the different behavior between 0.2.0 and 0.2.1 has to do with differences in the autogenerated version.py:

The 0.2.0 version.py has major/minor/bugfix explicitly set, while the 0.2.1 version only has the version as a string. This might result in pip not knowing the correct version number; but I'm not sure about how the interaction between conda - pip works.

Maybe this is related to #591?

Possible fixes:

(On me, workaround): Hardcode synphot 0.2.0 as a dependency for now.
(On me, proper): Ensure there are conda packages for everything I need.
Ensure conda package of synphot 0.2.1 plays along properly with pip. There seems other information in the version.py of 0.2.0 that might be useful to keep around, like the commit hash. But I wouldn't know where to begin.

Stuck on solving environment

Trying to install astroconda, keeps getting stuck on solving environment. I tried "conda update --all" and it did not help.

Cannot install ci-watson from this channel

Why is this failing? I see ci-watson in the recipes... I tried in both Python 3.6 and 3.7 environments. pip install ci-watson works fine.

$ conda install ci-watson
Solving environment: failed

PackagesNotFoundError: The following packages are not available from current channels:

  - ci-watson

Current channels:

  - http://ssb.stsci.edu/astroconda/linux-64
  - http://ssb.stsci.edu/astroconda/noarch
  - https://conda.anaconda.org/astropy/linux-64
  - https://conda.anaconda.org/astropy/noarch
  - https://conda.anaconda.org/conda-forge/linux-64
  - https://conda.anaconda.org/conda-forge/noarch
  - https://repo.anaconda.com/pkgs/main/linux-64
  - https://repo.anaconda.com/pkgs/main/noarch
  - https://repo.anaconda.com/pkgs/free/linux-64
  - https://repo.anaconda.com/pkgs/free/noarch
  - https://repo.anaconda.com/pkgs/r/linux-64
  - https://repo.anaconda.com/pkgs/r/noarch
  - https://repo.anaconda.com/pkgs/pro/linux-64
  - https://repo.anaconda.com/pkgs/pro/noarch