I am trying to exclude all generated files from a package using the following analysis_options.yaml file.
include: package:pedantic/analysis_options.yaml
analyzer:
strong-mode:
implicit-casts: false
implicit-dynamic: false
exclude:
- lib/**.g.dart
I still get errors for a file called lib/store/state/presentations_state.g.dart breaking the rule implicit_dynamic_parameter. If I exlcude **.g.dart without the lib/ prefix, dartanalyzer works properly, but the dart-code.dart-code VS Code plugin reports Undefined alias. dart(parse_error) somewhere in the first line of the YAML file, leaving the whole project marked as having an error.
I could reproduce this in both monorepos having multiple packages and single packages as well.
I put the following to the analysis_options.yaml which worked for me:
analyzer:
exclude:
- '**.freezed.dart'
- '**.g.dart'
- '**.gr.dart'
- '**/generated_plugin_registrant.dart'
All files matching the patterns are no longer analysed, independent of its location in the file path.
The quotation marks are necessary to prevent syntax errors in the yaml
See https://github.com/dart-lang/source_gen/tree/master/source_gen#configuring-combining_builder-ignore_for_file
Assuming the generator you use is based on package:source_gen you can use this trick to create the right ignores in the generated file!
https://github.com/kevmoo/peanut.dart/commit/9877105daecf59b8f5eb25431ac691a38a3e636c
https://github.com/kevmoo/stats/commit/bb2fefaa22fc11c10acfe2f6418b3abba1e51909
https://github.com/kevmoo/build_cli/commit/619495c91caab873c2f48ac36a941c893d9b86b7
Related
This bounty has ended. Answers to this question are eligible for a +100 reputation bounty. Bounty grace period ends in 14 hours.
frans is looking for an answer from a reputable source.
I have a working set of JJB YAML files successfully creating jobs and folders.
I now want to make certain values I use inside those YAML files configurable i.e. when running jenkins-jobs test|update -r jobfolder I want to set values for folder prefixes (to not damage existing production jobs), names for branches, nodes etc.
I don't want to use JJBs defaults approach for this since I'm already using it for configuration at a different place and it results in conflicts when used in projects and jobs together.
The ideal way of doing this I can think of would be a way to call JJB like this
jenkins-jobs test|update --define "folder-prefix=experimental/,node=test-node" -r jobfolder
Giving me variables I can use in the actual job definition files.
Since this option seemingly doesn't exist, I'm currently trying to provide files which contain those variables and somehow 'inject' them in my project.
Those are the approaches I can think of:
1 - having different configuration folders with YAML files inside, I would use like this:
jenkins-jobs test -r experimental-config:jobfolder
jenkins-jobs test -r production-config:jobfolder
with experimental-config and production-config being folders with additional files containing my configuration I can switch between.
But unfortunately I don't know how I would reference values I've defined in different yaml files. Is that even possible?
2 - having include files like described in the documentation
While that sounds promising I didn't manage to actually make this run. I tried to turn the following 'configuration header' I'm already using:
- dynamic-config: &dynamic-config
name: "dynamic-config"
folder-prefix: "experimental/"
node: "test-node"
[Rest of the file making use of dynamic-config]
into something making use of the !include statement like this:
!include: dynamic-config.yaml.inc
[Rest of the file making use of stuff defined in dynamic-config.yaml.inc]
giving me a seemingly unrelated parser error:
yaml.parser.ParserError: expected '<document start>', but found '<block sequence start>'
in "/home/me/my/project.yml", line 11, column 1
so I tried this snippet, which looks more like the example by putting it inside an existing element:
- dynamic-config: &dynamic-config
name: "dynamic-config"
!include: dynamic-config.yaml.inc
giving me a different error but still an error:
yaml.scanner.ScannerError: while scanning a simple key
in "/home/me/my/project.yml", line 7, column 5
could not find expected ':'
in "/home/me/my/project.yml", line 8, column 5
In both cases it doesn't make a difference whether or not the specified include file exists or not, which makes me doubt you can just 'include' a file like this at all.
What am I doing wrong here? Is there a more obvious / straight forward way to customize a jenkins-jobs run?
Update:
I somehow managed to use the !include tag for individual items now, like this:
- dynamic-config: &dynamic-config
name: "dynamic-config"
folder-prefix: !include: job-configs/active/folder-prefix.inc
branch-name: !include: job-configs/active/branch-name.inc
node-name: !include: job-configs/active/node-name.inc
But I wasn't able to put the whole dynamic-config element (with the anchor) into an include file yet.
2nd update:
Looks like I'm trying something similar as the guy from this question.
Can someone confirm, that this is currently still a problem? What's the JJB way of handling this?
Can someone tell me how to get protoc to generate dart files with a leading library directive?
I'm using the dart-protoc-plugin (v0.10.2) to generate my dart, c++, c#, js and java models from proto files. I was under the impression there was no way to get protoc to add a 'library' directive to the generated dart files, until I noticed the directive appearing in another project (see date.pb.dart).
If I take the same file (date.proto) I cannot get protoc to generate a dart file containing a 'library' directive.
In short: I want to take a .proto file with the following content
syntax = "proto3";
package another.proj.nspace;
message MyObj {
...
}
and produce a .dart file with a leading 'library' directive similar to the following snippet
///
// Generated code. Do not modify.
///
// ignore_for_file: non_constant_identifier_names,library_prefixes
library another.proj.nspace;
...
NOTE: I don't care about the actual value of the directive since I can restructure my code to get the desired result. I just need a way for protoc to add the library directive...
The basic command I'm using to generate the dart files is
protoc --proto_path=./ --dart_out="./" ./another/proj/nspace/date.proto
Unfortunately the dart-protoc-plugin's README isn't very helpful and I had to go through the source to find out which options are available; and currently it seems like the only dart-specific option is related to grpc.
I've tried options from the other languages (e.g. 'library', and 'basepath') without any success.
It would simplify my workflow quite a bit if this is possible, but I'm starting to get the impression that the library directive in date.pb.dart is added after the code was generated...
After asking around a little bit, it seems that the library directive was removed from the protoc plugin at some stage (see pull request), thus it is no longer supported.
I am busy making a sublime text plugin/package that will ease development of lua scripts in my workplace.
We have several lua files with different extensions depending on their purpose. I want ST3 to give the proper lua syntax to these files.
I know you can set ST3 to remember syntax for a specific file extension and this is saved as a (in my case) Lua.sublime-settings file in AppData\Roaming\Sublime Text 3\Packages\User
However, if I put this file in my new plugin's folder, it's ignored.
Am I doing something wrong or is what I want not possible?
This doesn't work because syntax specific settings are only loaded from the package that defines the syntax and from the User package (so the user can customize them).
The following is a quote from the official documentation on settings:
Settings files are consulted in this order:
1. Packages/Default/Preferences.sublime-settings
2. Packages/Default/Preferences (<platform>).sublime-settings
3. Packages/User/Preferences.sublime-settings
4. <Project Settings>
5. Packages/<syntax>/<syntax>.sublime-settings
6. Packages/User/<syntax>.sublime-settings
7. <Buffer Specific Settings>
The only places where <syntax> is referenced is from the package itself and from the user package.
If I had to guess, I would say that this is because outside of the original package author that defined the syntax, all other settings would be considered user customizations, and those settings need to be in the User package (specifically in the root of it) to ensure that they're loaded last.
A simple (but undesirable) solution would be to document for the user that they have to take this step manually.
Another approach would be to add some plugin code that extends the settings when your plugin is loaded:
def plugin_loaded():
settings = sublime.load_settings("Lua.sublime-settings")
extensions = settings.get("extensions", [])
if "blarb" not in extensions:
extensions.append("blarb")
settings.set("extensions", extensions)
sublime.save_settings("Lua.sublime-settings")
If you go this route you may want to include an extra sentinel setting somewhere (in settings specific to your package or some such) that says if you did this or not instead of just forcing the setting in as the example above does.
In practice you would then check if you've set that sentinel or not instead of forcing the extension in, so that if the user decides to use some other syntax for your files you're not forcing them into the Lua syntax.
It's also possible to define your own syntax that just embeds the standard Lua syntax, which allows this to Just Work™ without having to write any code or have the user do anything:
%YAML 1.2
---
name: Blarb
scope: source.lua
file_extensions:
- blarb
contexts:
main:
- include: scope:source.lua
When you do this, the scope in the file will still be source.lua because that's what the scope in the syntax file says. and the status line will set the syntax name to Blarb. You could modify either of those to change the top level scope or displayed name, if desired.
An example would be to change the scope to source.blarb so that you could create key bindings/snippets that only apply to Lua files of your specific variant.
A potential downside/feature of this is that since the name of the syntax specific settings comes from the name of the file that provides the syntax, if the user has any Lua specific settings, they won't apply to your Blarb files by default.
Similarly anything that's specific to Lua by checking for a scope of source.lua won't work in Blarb files for same reasons, which may or may not be an issue.
I've created an app that requires some configuration. The way I'm doing it now is a bit hacky and tedious -- If I'm developing locally, I include the "local" configuration file (a dart file that defines a few consts) and if deploying, I include a different dart file that defines the same consts with different values.
Ideally, there would be a way to define different configurations, which could be passed to pub serve/build. It seems like such an obvious need that I feel like something may already exist and I just haven't run across it yet. Is there? Or is something in the works?
Pub build does not support defining environment variables but you can use fromEnvironment method, for example, on String:
String.fromEnvironment(String name, {String defaultValue})
Returns the string value of the environment declaration name.
Environment declarations are provided by the surrounding system
compiling or running the Dart program. Declarations map a string key
to a string value.
Or make it "fancier" with transformers. It will allow you to automatically(on pub build or pub serve) get settings from pubspec.yaml or another source and embed them in to the code. For example sass(it is transformer) package supports settings of this form:
:::yaml
transformers:
- sass:
executable: /path/to/sass # Sass executable to use
compass: true # Include compass
line-numbers: true # Include line numbers in output
style: compact # Style of generated CSS
copy-sources: true # Copy original .scss/.sass files to output directory
With it you can do pretty much anything including source code modification.
Inspecting an archived app, I can see the full path listed for a few source code files in the app binary. Not all source code files are listed.
strings - the_binary_app | grep "\.m"
reveals
/Users/bbarnhart/myPath/myPath/App/path/path/SourceCodeFile.m
as well as a few others. I can not determine how the full paths for a few source code files are embedded in the app binary. I would like to remove them. Any ideas? Is this a build setting or is the project file slightly corrupted?
Some belong to a lib and others are files that belong to the project.
The __FILE__ macro expands to full path to the current file. This is one likely way you might be getting the paths into your executable. For example, the expansion of the assert macro includes the __FILE__ macro.
Look at the output of your strings | grep pipeline. For each of those files, go into your project in Xcode and open that file. Then go to the Related Files doodad and choose “Preprocess”:
Then search through the preprocessor output for the file's path. You will find lots of false positives, because there will be lots of # line number/path directives. You can ignore these, because they only produce debug output, which is not included in your executable file (unless you've done something weird with your build settings). You might find it faster to save the preprocessor output to a file, then open that file and pipe it through grep or use a regexp search/replace to delete all lines starting with #.
Find the other instances where your path appears as a string constant. For example, if you used the assert macro, you will find something like this:
(__builtin_expect(!(argc > 0), 0) ? __assert_rtn(__func__, "/Volumes/b/Users/mayoff/TestProjects/textViewChanged/textViewChanged/main.m", 16, "argc > 0") : (void)0);
That's a case where the path will end up embedded in your executable.
If that doesn't find all the places where you're embedding your path, try selecting “Assembly” from the Related Files doodad. The assembly will be full of comments containing your path; everything after # is a comment in the assembly output, so ignore those.
You will also see your paths in .file directives. I believe these only produce debug symbol output, which doesn't go into your executable, so you can ignore those too.
You will also see your paths in .asciz directives shortly after .section DWARF,... directives. This is more debug symbol stuff that you can ignore.
Look for the remaining cases where your path appears in the assembly output. You need to figure out how to eliminate these cases. How you do that will depend on the context in which the paths appear, so if you need more help, update your question with what you find.
Sounds like your code contains the __FILE__ macro somewhere.