I would like to write a .prettierignore file to target the files in a single directory, which is nested one level down from the root of the project. I figure the most elegant way to accomplish this is to use a negated pattern to ignore everything but the target directory.
So, I currently have this:
# Ignore all
/*
# but for /views
!src/views/
Running the npx prettier --write . command with that pattern (or similar variations) appears to match no files, and no files change. However, if I run the command without/views in the pattern, i.e. just !src, then prettier formats everything in the src directory, including all the files in /views.
What am I missing that I can't successfully target only the nested /views directory?
After some more searching, I found this solution, which accomplishes the outcome I was seeking, though, I don't quite understand how it works.
#ignore all
/*
#but don't ignore files or directories at root called src
!/src
#ignore everything in src dir?
/src/*
#but don't ignore views dir in src?
!/src/views
Why would that be necessary compared to just src/views?
Related
For my workflow, the scripts & snakefile are in a different directory than the output files. I specify the latter using the workdir directive, which seems to work fine.
Now in some cases there are static input files in other directories, whose paths I want to specify relative to the snakefile. According to the documentation, I should use workflow.get_source("path/relative/to/snakefile"). However this gives me
'Workflow' object has no attribute 'get_source'. Do I need some additional imports?
Looking at the documentation, it looks like what's used in the code example is workflow.source_path("path/relative/to/snakefile") rather than get_source - you can give that a try.
Otherwise, though I don't think it's officially documented, workflow.basedir gives you the path of the directory the Snakefile lives in, and you can build the rest of the path off that.
when I run nextflow, I get a .nextflow folder, but I can't find a way to change its location (i.e. it is't -work-dir). How can I change the location of the .nextflow folder?
I have looked at launchDir but it seems that is a read-only implicit variable and cannot be overwritten in the CLI, also, the --launchDir option is only valid for the k8s scope (see original chat in gitter)
I'm using Nextflow 20.10.0 build 5430.
Keeping things neat and tidy is admirable. From this comment, it looks like the only way (without doing crazy things...) is to change to the directory you want your .nextflow cache directory to live and point all other options (i.e. -work-dir, -log etc) away to a separate directory:
If you want .nextflow in dir A and the pipeline work dir in B:
cd A
nextflow run -w B
The .nextflow has to be in the launching
directory to properly maintain the history of the executions.
Question
When building Singularity images using definition files, is there a way to specify the path to a file on the host system relative to the definition file (i.e. independent of where the build command is called)?
Example to Illustrate the Problem
I have the following files in the same directory (e.g. a git repository):
foobar.def
some_file.txt
foobar.def looks as follows:
Bootstrap: library
From: ubuntu:20.04
Stage: build
%files
# Add some_file.txt at the root of the image
some_file.txt /some_file.txt
This works fine when I build with the following command in the directory which contains the files:
singularity build --fakeroot foobar.sif foobar.def
However, it fails if I call the build command from anywhere else (e.g. from a dedicated "build" directory) because it searches some_file.txt relative to the current working directory of the build command, not relative to the definition file.
Is there a way to implement the definition file such that the build works independently of where the command is called? I know that I could use absolute paths but this is not a viable solution in my case.
To make it even more complicated: My actual definition file is bootstrapping from another local image, which is located in the build directory. So ideally I would need a solution where some files are found relative the working directory while others are found relative to the location of the definition file.
Short answer: Not really
Longer answer: Not really, but there's a reason why and it shouldn't really matter for most use cases. While Docker went the route of letting you specify what your directory context is, Singularity decided to base all of its commands off the current directory where it is being executed. This also follows with $PWD being auto-mounted into the container, so it makes sense for it to be consistent.
That said, is there a reason you can't run singularity build --fakeroot $build_dir/foobar.sif foobar.def from the repo directory? There isn't any other output written besides the final image and it makes more sense for the directory with the data being used to be the context to work from.
I am trying to backup some of the essential folders in the / in my ubuntu system. I am using
sudo rsync -aAXv --delete --include="/etc" --include="/home" --include="/usr/local" // /home/$USER/Desktop/bkup/
This command should only copy /etc, /home, /usr/local dirs and leave the rest of the files. But, when I run this command this copies every dir and every file in the / dir.
I am not sure what wrong I am doing here.
Includes without any excludes are meaningless.
--exclude='*' would exclude everything not explicitly included, from every subfolder, even the included ones.
--exclude='*/' would exclude every directory not explicitly included, but allow copying files within included directories (and the root).
--exclude='/*' would exclude all root directories and files not explicitly included, but allow all directories and files within included directories. You probably want this one.
You should add your exclude rule after your include rules. The rule is that, for each directory and file, it's the first matching include/exclude rule that matters, and the default (when no rule matches) is to include.
By "root" I mean the root of the copied directory, not the root of the whole file system.
P.S. Your command also has the destination directory inside the source directory; you probably want an exclude rule for that!
I want to set up my HelloWorld intellij-erlang project with all files in the same directory so I can easily switch between IDEA and emacs/vim.
<my-project>/hello.erl
<my-project>/hello.beam
Now, if I configure the output directory to be the same as the source, hello.erl gets emptied as part of the build and the compilation fails.
I assumed it's something to do with copying resources to the output directory, so I've configured intellij-erlang to exclude *.erl from the resources with a !?*.erl pattern, but this does not have any effect, hello.erl still gets emptied before the compilation takes place.
As an experiment, I've also tried using separate src and out directories, and intellij-erlang always copies the *.erl to out irrespective of the resource patterns.
Based on all this, I would conclude that intellij-erlang cannot work with all files in the same directory. Have I missed anything?
Erlang programs should be build on standard OTP directory structure. Build tools like rebar (used by intellij) or erlang.mk build on this conventions. And so should all IDE's.
Intellij does it, just like you notice. And so does Emacs's plugin (that I use and can confirm). I would guess so does Vim's one.
So if you would like to be able to switch easily between your IDE's you should try to keep to this convetion of keeping you source files in src and compiled files in bin (and headers in include).