Skip to content
This repository has been archived by the owner on Jan 30, 2019. It is now read-only.

ENH : sort activate.d scripts to control order #66

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

tacaswell
Copy link

Sort the found shell scripts to allow the user to control which order
the scripts are run in.

I don't know enough to make the parallel change in the windows files.

The reason I want this is because I am trying to use conda packages to manage the setup/teardown of a test environment where I need to start a server-like thing, but some environmental variables need to be set first.

It currently sorts on the path to the scripts which is fine if you don't have anything in directories. I am not convinced that this is not the desired behavior, just aware of the concern.

Sort the found shell scripts to allow the user to control which order
the scripts are run in.
@tacaswell
Copy link
Author

@tswicegood I was in the process of making sure my PR message was sensible. How did you even notice that commit existed?

@tswicegood
Copy link
Contributor

Spoke too soon on the commit! Here's the PR.

I saw it existed because I happened to be looking at the network graph and see your commit out there by itself. This change makes perfect sense, though I would like to get it into the Windows side too if possible. I think we need to switch it up to use DIR /b per this page. Any chance you could take a stab at it?

@tacaswell
Copy link
Author

I have not used a windows box for anything but video games in almost a decade now. I can try to make changes, but don't have anyway to test if they even run....

It looks like there is already an asymmetry, on the *nix side it will find all *.sh files recursively but on windows only *.bat files at the top level of [de]activate.d.

@campos-ddc
Copy link
Contributor

Is that necessary?

I tested the current Windows implementation locally and it looks like for %%g in (*.py) do echo "%%g" already sorts alphabetically.

@tacaswell
Copy link
Author

testing this again, it looks like find does return them in a some-what random order:

(dd_3k)tcaswell@tcaswellpc1:~/bnl_source/conda-prescriptions$ find ./ -name "*.sh"         
./master/pyepics/build.sh
./master/ophyd/build.sh
./master/bubblegum/build.sh
./master/scikit-xray/build.sh
./master/pyolog/build.sh
./master/metadatastore/build.sh
./master/lmfit/build.sh
./master/channelarchiver/build.sh
./master/filestore/build.sh
./master/build-submit.sh
./master/dataportal/build.sh
./master/vistrails-upstream/build.sh
./master/xraylib/build.sh
./releases/pyspec/0.2.0/build.sh
./releases/ophyd/v0.0.5/build.sh
./releases/ophyd/v0.0.3/build.sh
./releases/ophyd/v0.0.7rc1/build.sh
./releases/ophyd/v0.0.4/build.sh
./releases/ophyd/v0.0.7rc2/build.sh
./releases/ophyd/v0.0.6/build.sh
./releases/ncurses/5.9/build.sh
./releases/pcaspy/0.5.1/build.sh
./releases/python/3.4.2/build.sh
./releases/python/2.7.9/build.sh
./releases/service_identity/14.0.0/build.sh
./releases/certifi/14.05.14/build.sh
./releases/metadatastore/v0.0.5/build.sh
./releases/metadatastore/v0.0.3/build.sh
./releases/metadatastore/v0.0.4/build.sh
./releases/keyring/5.3/build.sh
./releases/mongoengine/0.8.7/build.sh
./releases/protobuf/2.6.0/build.sh
./releases/conda_etc/build.sh
./releases/tifffile/0.3.1/build.sh
./releases/lmfit/0.8.3/build.sh
./releases/lmfit/0.8.1/build.sh
./releases/filestore/v0.0.3/build.sh
./releases/filestore/v0.0.2/build.sh
./releases/filestore/v0.0.4/build.sh
./releases/carchivetools/1.9.0/build.sh
./releases/sphinxcontrib-napoleon/0.2.8/build.sh
./releases/characteristic/14.3.0/build.sh
./releases/vistrails/2.1.4/build.sh
./releases/build-submit.sh
./releases/readline/6.2/build.sh
./releases/reindent/0.1.1/build.sh
./releases/pims/0.2.2/pims/build.sh
./releases/hgtools/6.3/build.sh
./releases/pyasn1-modules/0.0.5/build.sh
./releases/tzlocal/1.1.2/build.sh
./releases/epics-base/R3.14.12.4/build.sh
./releases/dataportal/v0.0.5/build.sh
./releases/dataportal/v0.0.3/build.sh
./releases/dataportal/v0.0.2/build.sh
./releases/dataportal/v0.0.7rc1/build.sh
./releases/dataportal/v0.0.4/build.sh
./releases/dataportal/v0.0.6/build.sh
./releases/sphinx-bootstrap-theme/0.4.5/build.sh
./releases/xraylib/3.1.0/build.sh
./beamlines/CSX2/configuration/build.sh
./beamlines/CSX1/configuration/build.sh
./beamlines/IXS/configuration/build.sh
./beamlines/CHX/configuration/build.sh
./beamlines/SRX/configuration/build.sh
./beamlines/dev_env/configuration/build.sh
./beamlines/XPD/configuration/build.sh
./beamlines/HXN/configuration/build.sh
(dd_3k)tcaswell@tcaswellpc1:~/bnl_source/conda-prescriptions$

@campos-ddc
Copy link
Contributor

Worth noting that the current Windows implementation does not look into subdirectories:

X:\conda-env\conda_env : $ for %%g in (*.py) do echo "%%g"
"compat.py"
"env.py"
"exceptions.py"
"print_env.py"
"yaml.py"
"__init__.py"

While unix does (I'm using your sort in this example):

[dev@localhost conda_env]$ for f in $(find . -name "*.py" | sort); do echo $f; done
./cli/__init__.py
./cli/main_create.py
./cli/main_export.py
./cli/main_list.py
./cli/main.py
./cli/main_remove.py
./cli/main_update.py
./cli/main_upload.py
./compat.py
./env.py
./exceptions.py
./__init__.py
./installers/base.py
./installers/conda.py
./installers/__init__.py
./installers/pip.py
./print_env.py
./specs/binstar.py
./specs/__init__.py
./specs/yaml_file.py
./utils/__init__.py
./utils/uploader.py
./yaml.py

@tswicegood
Copy link
Contributor

That's a good find, @campos-ddc. The intended behavior is to only go one level so a -maxdepth should probably be added.

@malev
Copy link
Contributor

malev commented Jul 25, 2015

@tacaswell I'm not sure if I understand what is the intention of this PR

@tacaswell
Copy link
Author

If you have a collection of packages which need to activation scripts run and there is some interdependency on that order. Ex 01-packageA.sh and 02-packageB.sh which ensures that packageA's start up script is run before packageB's.

This is inspired by how the init.d folder is organized in debian.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants