add automated container build to provide the library about expfactoryr HOT 20 CLOSED

From packages names I see on CRAN, nobody seems to break the "no dots" rule, but many break the "no caps" rule. Maybe I should ask about relative merits on Stack Overflow.

from expfactoryr.

The assertive naming scheme arose because it was originally a single package. It grew too big, so I split it into several smaller packages. Now assertive itself just imports and reexports all the functions from each of the assertive.* packages. The idea is that if you are making your own package, you want the smallest possible set of dependencies, you you can depend upon only the assertive.* functions that you use. By contrast, if you are working interactively, you don't want to have to think about which assertive.* package the function you want is contained in, so you can just write library(assertive) and get everything. I used the same tactic with the rebus package.

As a general principle, using lowercase names makes them easier to type. I'd favor something like

expfactory.base (core library)
expfactory.stroop
expfactory.breathcounting
expfactory.statemindfulnessscale
expfactory.fivefacetmindfulnessquestionnaire
expfactory.attentionnetworktest

from expfactoryr.

I'm huge +1 to what @richierocks has to say! I like the examples provided (with . and no weird capitalization) and think we should do exactly that.

from expfactoryr.

okay I'm doing some testing in the survey repo to see if I can install expfactoryR THEN the functions in the experiment, something like:

            echo "Installing package efsmsr"
            R -e "devtools::install_github('expfactory/expfactoryR')"
            #R -e "devtools::install_local('efsmsr')"
            cd /tmp/src/efsmsr
            R -e 'devtools::check()'
            R -e 'devtools::test()'

I'm sure it will fail at least 43 times before it gets working, I'm ok with this :)

from expfactoryr.

And what does "efsmsr" mean?

from expfactoryr.

yep that worked! Wicked cool :) I think we should add the same install routine here, to test the expfactoryR package itself. Did you write tests for it?

from expfactoryr.

Yes, there are tests for expfactoryr.

The namespace constraints in R are quite restrictive, so I've gone for the general pattern ef for experiment factory, followed by some sort of abbreviation of the experiment/survey, followed by r. Hence efsmsr.

from expfactoryr.

why not be more explicit and go for the whole string at least, e.g., expfactory-stroop and have it be an r package? Why does it have to be short, and why does it have to end in "R." ?

from expfactoryr.

• ef was to save typing, but yes expfactory might be clearer
• "the name can only consist of letters, numbers and periods" i.e. no dashes

Given the above, if we break the allowed but discouraged . ("I recommend against using periods in package names because it has confusing connotations ") we could have

• expfactory.stroop
• expfactory.breath.counting (a bit clunky for multi-word tasks)

from expfactoryr.

The more I read the rulez, the more they seem to have been designed to obfuscate the relationship between a package name and what it does! My love-hate relationship with R continues to unfold... :)

from expfactoryr.

I am ok with mostly anything, but I think the package should have some logical underpinning. So "efsmsr" is not great, but any of the other ones above would be ok.

from expfactoryr.

Authors seem to ignore the no CamelCase advice, so maybe expfactoryCamelCaseTaskName, which would give

• expfactory (core library)
• expfactoryStroop
• expfactoryBreathCounting
• expfactoryStateMindfulnessScale
• expfactoryFiveFacetMindfulnessQuestionnaire
• expfactoryAttentionNetworkTest
• ...

from expfactoryr.

What's wrong with the dot one, and then we would have the expfactory namespace for all experiments?

from expfactoryr.

In Python a "dot" would come down to a different library (meaning if the library is called "expfactory" and you do from expfactory.utils import that would come down to a top level folder called expfactory with a module (file) called utils.py in the folder. I think what we would want to do is have it so that if a user installs an expfactory module, it's sort of a "submodule" for some parent namespace (expfactory). Like:

expfactory/
    stroop
    breatheCountingTask

etc.

from expfactoryr.

Yeah, that would be great ... if R had the concept of hierarchical namespaces which mapped nicely onto filesystems. AIUI it has neither. It just dumps all packages into (global or local) lib dirs. I imagine this is the origin of the "no dots" rule, i.e. don't make namespaces look hierarchical when/because they're not. Breaking the CamelCase rule makes sense to me so that package names are easier to read, at the expense of being harder to type.

from expfactoryr.

Why not break the rule with dots (or some other allowable character?) It looks nicer, more pythonic :)

from expfactoryr.

I wonder whether the rules are then specifically to prevent it looking like something it isn't i.e. something moRonic. I'll take a reading from SO.

from expfactoryr.

I've asked this question on SO.

from expfactoryr.

Hmm. It got put on hold because it was deemed the answers would be opinion. I don't think I can re-word it to remove the hold.

There are groups of packages that use ., e.g. assertive.*. I've emailed one of the authors to get an opinion.

from expfactoryr.

OK. I'll initiate a mass renaming ASAP. :)

from expfactoryr.