Skip to content

CDS MOC test should use overwrite  #1608

Closed

Description

@bsipocz

I run into this test failure locally due to the parametrization of the test.

For the test, I think we should either use overwrite=True or preferably a temp file, but with a very quick look in the relevant code in astroquery/cds/core.py, I find it a bit odd, too that the path for moc is created based on the current directory rather than from a kwarg in self.path_moc_file, resulting the test file being dumped into a site-packages dir in this case.

cc @bmatthieu3


self = <astroquery.cds.tests.test_mocserver_remote.TestMOCServerRemote object at 0x1355bf450>, moc_order = 10

    @pytest.mark.skipif('mocpy' not in sys.modules,
                        reason="requires MOCPy")
    @pytest.mark.parametrize('moc_order', [5, 10])
    def test_moc_order_param(self, moc_order):
        moc_region = MOC.from_json({'0': [1]})
    
        result = cds.query_region(region=moc_region,
                                  # return a mocpy obj
                                  return_moc=True,
                                  max_norder=moc_order,
>                                 get_query_payload=False)

astroquery/cds/tests/test_mocserver_remote.py:79: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
astroquery/cds/core.py:122: in query_region
    response = self.query_region_async(get_query_payload=get_query_payload, region=region, **kwargs)
astroquery/cds/core.py:203: in query_region_async
    request_payload = self._args_to_payload(**kwargs)
astroquery/cds/core.py:257: in _args_to_payload
    region.write(self.path_moc_file, format="fits")
/usr/local/lib/python3.7/site-packages/mocpy/serializer.py:91: in write
    serialization.writeto(path, overwrite=overwrite)
/usr/local/lib/python3.7/site-packages/astropy/utils/decorators.py:521: in wrapper
    return function(*args, **kwargs)
/usr/local/lib/python3.7/site-packages/astropy/io/fits/hdu/hdulist.py:926: in writeto
    fileobj = _File(fileobj, mode=mode, overwrite=overwrite)
/usr/local/lib/python3.7/site-packages/astropy/utils/decorators.py:521: in wrapper
    return function(*args, **kwargs)
/usr/local/lib/python3.7/site-packages/astropy/io/fits/file.py:193: in __init__
    self._open_filename(fileobj, mode, overwrite)
/usr/local/lib/python3.7/site-packages/astropy/io/fits/file.py:563: in _open_filename
    self._overwrite_existing(overwrite, None, True)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <[AttributeError("'_File' object has no attribute '_file'") raised in repr()] _File object at 0x130b32450>
overwrite = False, fileobj = None, closed = True

    def _overwrite_existing(self, overwrite, fileobj, closed):
        """Overwrite an existing file if ``overwrite`` is ``True``, otherwise
        raise an OSError.  The exact behavior of this method depends on the
        _File object state and is only meant for use within the ``_open_*``
        internal methods.
        """
    
        # The file will be overwritten...
        if ((self.file_like and hasattr(fileobj, 'len') and fileobj.len > 0) or
                (os.path.exists(self.name) and os.path.getsize(self.name) != 0)):
            if overwrite:
                if self.file_like and hasattr(fileobj, 'truncate'):
                    fileobj.truncate(0)
                else:
                    if not closed:
                        fileobj.close()
                    os.remove(self.name)
            else:
>               raise OSError(f"File {self.name!r} already exists.")
E               OSError: File '/private/var/folders/dc/hsm7tqpx2d57n7vb3k1l81xw0000gq/T/astroquery-test-v9kq_d_8/lib/python3.7/site-packages/moc.fits' already exists.

/usr/local/lib/python3.7/site-packages/astropy/io/fits/file.py:453: OSError

Activity

  1. ManonMarchand commented on Jun 13, 2023

    @ManonMarchand
    Member

    Hi!
    Do you still have this issue with mocpy 0.12.3 ?

  2. bsipocz commented on Jun 13, 2023

    @bsipocz
    MemberAuthor

    I'm pretty sure this got resolved a while ago without any of us noticing the open issue, thanks for the ping.

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions