anaconda-client: anaconda upload silently fails

Hi,

I’m experiencing weird issues with anaconda upload silently failing.

  1. built a package:
conda skeleton pypi fastprogress
conda-build fastprogress

all was successful (this is just a pure python one-file module).

  1. tried to upload:
anaconda upload fastprogress-0.1.5-py36_0.tar.bz2
Using Anaconda API: https://api.anaconda.org
Using "stason" as upload username
Processing 'fastprogress-0.1.5-py36_0.tar.bz2'
Detecting file type...
File type is "conda"
Extracting conda package attributes for upload
Creating package "fastprogress"

that’s it. Nothing happens, no error message, nothing gets uploaded. (nothing appears under https://anaconda.org/stason/repo)

Please note that another team member was able to successfully upload this same package from his setup, but it doesn’t work on mine:

conda-build 3.15.1
conda 4.5.11
anaconda Command line client (version 1.7.2)
Python 3.6.6 :: Anaconda custom (64-bit)
ubuntu 18.04

Thank you.

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Reactions: 6
  • Comments: 27 (9 by maintainers)

Commits related to this issue

Most upvoted comments

I think i have narrowed this down. If you do a echo $? anaconda-client properly shows an error code of 1, but no output.

In upload.py:245 it needs to catch the exception. This snippet shows catching the exception, logging it and re-raising it:

        try:
            logger.info("About to upload")
            upload_info = aserver_api.upload(username, package_name, version, file_attrs['basename'], fd,
                                             binstar_package_type, args.description,
                                             dependencies=file_attrs.get('dependencies'), attrs=file_attrs['attrs'],
                                             channels=args.labels, callback=upload_print_callback(args))
            logger.info("after upload")
        except errors.Conflict:
            logger.info("Inside Except")
            upload_info = {}
            if args.mode != 'skip':
                logger.info('Distribution already exists. Please use the -i/--interactive or --force or --skip options '
                            'or `anaconda remove %s/%s/%s/%s', username, package_name, version, file_attrs['basename'])
                raise
            else:
                logger.info('Distribution already exists. Skipping upload.\n')
        except Exception as e:
                logger.info('Uncaught exception: %s' %  (str(e),))
                raise

The output looks like this:

Using Anaconda API: https://api.anaconda.org
Using "...." as upload username
Processing '/home/travis/miniconda/conda-bld/linux-64/......tar.bz2'
Detecting file type...
File type is "conda"
Extracting conda package attributes for upload
Creating package "......"
Creating release "1.5.1"
Uploading file "...."
About to upload
Uncaught exception: (u'Authentication token has expired', 401)

@bkreider let’s huddle on this very soon and work on getting a point release out there.

I just had this issue also, silent failure; added the code from @bkreider and got:

Uncaught exception: module 'base64' has no attribute 'encodestring'

It’s important to note that conda install anaconda-client will by default update Python, hence causing the hidden AttributeError: module 'base64' has no attribute 'encodestring' exception even if you are using, say, the conda/miniconda3 docker image that still ships Python 3.7.3 initially. You can avoid this by writing e.g. conda install python=3.8 anaconda-client.

If this does not help, see my comment in #564 on how to monkey-patch anaconda-client within a temporary conda environment using the patch proposed by @bkreider. This should give you an error message.

I have seen the same… I tried with anaconda-client 1.5.x and then I saw the issue, the token was expired… somehow the latest anaconda-client version eats that info when it fails, I think.

I would consider this as a regression for anaconda clinet. Downgrading the client to 1.5.5 seems to resolve the issue. Now i see the package released to anaconda.org …

https://anaconda.org/h2oai/h2oai_client/files

So my guess is there is some sort of permissions failure that goes undetected by the client.

@goanpeca, @ericdill and I just discovered a silent failure wil occur in another instance as well: when using the --private flag on an organization (-u) that doesn’t have private package privileges.

@stas00 I did, but I will take a look on monday!