Packages are removed on Windows

[pradal]

At least, on Windows, old packages (win-64) are removed during the build.
The error may come from appveyor-ci

[pfernique]

What do you mean ?
On Anaconda Cloud, if you upload a package that has the same name as an existing one, the one that you will upload will replace the existing one. If you don't want this, set the ANACONDA_FORCE environment to false in the config.bat file.
Note that this will cause your build to fail so you might want to remove the if errorlevel 1 exit 1 in the deploy_script.bat
Is this answering your problem or did you mean something else ?

[pradal]

No. In fact if you look at the anaconda channel, all the recent packages have been removed.
While no global build have succeed. So we can not install openalea.sconsx, even if some version exists some days ago.

[artzet-s]

Look that link : https://anaconda.org/openalea/repo/history?label=main

[artzet-s]

It's in the label main.

[pfernique]

This is really strange.
If this appens that means at each build it is upload then removed.
So, you builds should fail but if I look in your appveyor builds, there are built correctly.
And I see openalea.sconsx on your channels.
Are you sure it is not a relabelling from main to win-x86_64_release that is causing your installation failure ?

[pradal]

We found that when we try to install openalea.plantgl from openalea channel.
And we realise that most of the packages have desappear.

[pfernique]

When ? I need the error message because if I look to your Anaconda channel are packages seem to be here (including plantgl).
I can see in history the line
pradal removed the file win-64/openalea.plantgl-2.23.2-py27_1.tar.bz2 from the package openalea/openalea.plantgl 4 hours and 57 minutes ago
but if you look at the openalea.plantgl files It has also been added 4 hours and 57 minutes ago so I really think my first answer is what your looking for:
If you have an openalea.plantgll-2.23.2 in your main label and that AppVeyor has uploaded a new openalea.plantgll-2.23.2 during the release, it is then labelled win-x86_64-release and there is no more a openalea.plantgll-2.23.2 labelled main. To have a new openalea.plantgll-2.23.2 labelled main you need to wait for AppVeyor to finish the job with ANACONDA_RELEASE=true that will move all packages labelled win-x86_64-release to the main label.

[artzet-s]

So, why not just make a copy during the computing ? Why make a move of the main package in the win-x86_64-release and not a copy ? Otherwise every conda install during the C.I from openalea channel will fail, right ?

[artzet-s]

One more question, if the C.I fail at the end, the win-x86_64-release is deleted ? And all packages moved from main too ?

[pfernique]

The release labels are deleted only if the build success.
If not, you can comment in your appveyor.yml builds that succeded and only relaunch those which failed.
On success all packages built are moved on the main label.
On the move againt copy, I have no choice, this is the way anaconda cloud is built: labels don't change the name of the file and if a file has the name of an existing file, it is replaced when uploaded.
The only way to change is to set ANACONDA_FORCE to false but this cause an error in the deploy_script.bat. It is sufficient to remove all if errorlevel 1 exit 1 to remove errors. But this also means that if an upload fail for any other reasons, the error is not raise.

[artzet-s]

Ok Thanks for your response, I understood. Maybe a another organization/account on anaconda can be a easy solution. Like a "openalea-release" (or random name like "fsT7goD17qs9") organization where everything is temporary uploaded for the C.I . And if success push and erase package with the same name in the "openalea" organization.

[pfernique]

But you can't create organization from the Anaconda Cloud API.
I think the better is to obtain a md5sum of the package uploaded and the package built if they have the same version.
If they:

• differ it means that 2 packages with the same version do not have the same content, then an error should be raised.
• are the same, then there is no problem induced by the fact the new package is not uploaded.

Note that it is also possible to use new Conda Build names to add in the hash of the package name a part tied to the release number (e.g., by adding an environment variable representing it).