Repository: conda/conda-build

Issue:
conda cannot be built with conda-build 3
I can't build conda with CB3 3.0.11.That used to work in CB2...

I am not sure, but I think there are two bugs regarding the handling of the activate/deactivate scripts.

### idea behind the (special) current handling of conda
just repeating what I understood to make sure that my conlcusions are right

- `always_include_files` will include the activate/deactivate/conda files, which will be produced by the build process.
- initially after build-env creation they will be symlinks and in build.sh they will be unlinked
- build.sh produces new activate/deactivate and conda scripts
- because always_include_files is specified they are actually included into the package and not dropped


### Problem1: always_include_files doesn't work anymore for activate/deactivate/conda

When i build the recipe i get errors for activate/deactivate/conda:

```
ERROR:conda_build.utils:invalid recipe path: /root/miniconda3/conda-bld/conda_1503661965202/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/bin/conda
```

It seems the new logic in https://github.com/conda/conda-build/blob/38dc7778f17035956c3f1d8f311978152282ce59/conda_build/utils.py#L770 checks whether these are available, but at the time of checking they are not yet. The problem is, that as a result of not being present, the 3 files get dropped from the `always_include_files`-list.

### Problem2: symlinking conda

It seems there is a "symlink_conda" function, that replaces the newly generated 3 files by simlinks and doesn't include them. 

There was a hack that makes conda build by @mingwandroid here: #2167. But that logic got reverted in #2251 . Unfortunately adding back the hack doesnt work, because of problem 1 (the 3 files are not in always_include_files). So if problem 1 would be fixed, something would probably need to be done about problem 2, because uncoditionally calling symlink_conda will probably replace our files...

@msarahan Am I on the right track at all? Is the way of building conda still alright, or is there an alternative?


Discussion:
yes seems possible indeed, the recipe is roughly like mine... 

for me its not working with the above problems...  Is there a build log on your build? 
It seems broken.  I don't know exactly how we've been building it - I haven't been the one doing that work, and you're the first to report this issue.  I'll look into it.

Resolving patch:
diff --git a/conda_build/build.py b/conda_build/build.py
--- a/conda_build/build.py
+++ b/conda_build/build.py
@@ -996,8 +996,7 @@ def build(m, post=None, need_source_download=True, need_reparse_in_env=False, bu
         if (not m.config.dirty or not os.path.isdir(m.config.build_prefix) or
                 not os.listdir(m.config.build_prefix)):
             environ.create_env(m.config.build_prefix, build_actions, env='build', config=m.config,
-                               subdir=m.config.build_subdir, is_cross=m.is_cross,
-                               always_include_files=m.always_include_files())
+                               subdir=m.config.build_subdir, is_cross=m.is_cross)
 
         # this check happens for the sake of tests, but let's do it before the build so we don't
         #     make people wait longer only to see an error
diff --git a/conda_build/environ.py b/conda_build/environ.py
--- a/conda_build/environ.py
+++ b/conda_build/environ.py
@@ -723,7 +723,7 @@ def get_install_actions(prefix, specs, env, retries=0, subdir=None,
 
 
 def create_env(prefix, specs_or_actions, env, config, subdir, clear_cache=True, retry=0,
-               locks=None, is_cross=False, always_include_files=[]):
+               locks=None, is_cross=False):
     '''
     Create a conda envrionment for the given prefix and specs.
     '''


Test patch: