Considering there is a package in a module :
package com.example.apple
Is it possible to exclude that particular package of that module instead of commenting each individual files of that package one by one?
Say I have multiple modules as :
myProject/
/module1
/com.example
/somepackage1
file1.scala
file2.scala
file3.scala
..........
/somepackage2
filep1.scala
filep2.scala
filep3.scala
/module2
/com.example
/somepackage3
/somepackage3
/module3
.......similarly
So here , if we can exclude somepackage1 in our built.sbt, it would be great instead of commenting file1,file2,file3...individually.
Considering that I dont want that package to not get compiled.
Related
I have project structure
-core_data
-core_domain
-core_ui
-core_launcher
The dependency of these 4 projects is
core_launcher -> core_ui -> core_domain -> core_data
4 projects are located in the same directory and I include one to another via pubspec.yaml file (for example core_launcher/pubspec.yaml):
dependencies:
flutter:
sdk: flutter
core_ui:
path: ../core_ui
The same thing I do with all projects to make dependency hierarchy.
The problem is that I can import all files from core_ui subproject when I'm currently editing some file in core_launcher but VSCode doesn't see any classes from his parents
(core_domain & core_data).
However, I can input import 'blah-blah-blah manually and VSCode see this class and import works well, but I can't do that with hit Alt+Enter that I do for fast-import.
So, I'm wondering why autocomplete is not working for inherited libraries.
Somebody had the same issue?
Code completion will only show classes from your direct dependencies. There are two possible reasons for this:
Relying on transitive dependencies is not a good idea, because it's possible that your dependencies will remove or change their dependencies and not consider that a breaking change.
If code completion listed all classes from all transitive dependencies the code completion list would be huge and include classes from packages you do not recognise (because they are just other packages dependencies). This would be a bad user experience and make it easy to accidentally rely on packages that are not listed in your pubspec.yaml.
The fix is to explicitly list core_domain and core_data in your pubspec.yaml too, because if your project is using classes from them, then they are dependencies.
Trying to use Svg and Svg.Attributes. Getting the error message
I cannot find module 'Svg'.
Module 'Main' is trying to import it.
Potential problems could be:
* Mispelled the module name
* Need to add a source directory or new dependency to elm-package.json
I'm certain that there aren't any spelling errors because I copy and pasted the imports from a tutorial. Where do I install this library?
The tutorial I'm going through is the one elm-lang.org, specifically the section on time.
You need the elm-lang/svg package as a dependency in your elm-package.json. Run elm package install elm-lang/svg in the project directory.
I have a Swift library with a core module plus optional bonus modules. I would like to use the following directory layout, mapping to exported Swift package names as shown:
Taco/
Source/
Core/ → import Taco
Toppings/ → import TacoToppings
SideDishes/ → import TacoSideDishes
To my eyes, that’s a sensible-looking project layout. However, if I’m reading the docs right, this will pollute the global module namespace with unhelpful names like “Core”. It seems that SwiftPM will only export a module whose name is identical to the directory name, and thus I have to do this:
Taco/
Source/
Taco/
TacoToppings/
TacoSideDishes/
Is there a way to configure Package.swift to use the tidier directory layout above and still export the desired module names?
Alternatively, is it possible to make the Core, Toppings, and SideDishes modules internal to the project, and export them all to the world as one big Taco module?
There is not currently a clean way to do this, but it seems like a reasonable request. I recommend filing an enhancement request at http://bugs.swift.org for it.
There is one "hacky" way you can do this:
Create your sources in the desired internal layout:
Sources/Core
Sources/Toppings
Add additional symbolic links for the desired module names:
ln -s Core Sources/Taco
ln -s Toppings Sources/TacoToppings
Add an exclude directive to the manifest to ignore the non-desired module name:
let package = Package(
name: "Taco",
exclude: ["Sources/Core", "Sources/Toppings"]
)
is it possible to make the Core, Toppings, and SideDishes modules internal to the project, and export them all to the world as one big Taco module?
No, unfortunately there is no way to do this currently, and it requires substantial compiler work to be able to support.
I can't use functions of custom subdirectories.
My Code Organziation
I have under "src" a path hierarchy like
a/b
with all my directories and go-Files (it is the "root" of my project). The directories contain no subdirectories and it works fine. So the deepest path is "a/b/c". E.g. I have
a/b/c
and
a/b/d
with some go-files. Import of "a/b/d" and calling a function with "d.DoSomething()" from a file in "a/b/c" works fine.
Problem description
Now I want ot reorganize "a/b/d". I move some files from "a/b/d" to
a/b/d/e
and the rest of the files to
a/b/d/f
If try to import "a/b/d/e" with import-statement
import ( "a/b/d/e" )
from the same file in "/a/b/c" and want to call "e.DoSomething()" (it is the place, where the file with the "DoSomething-function" moved to), I get an error at the line, where I call "e.DoSomething()": "undefined: e".
While searching for a result, I've nowhere seen examples with deeper path hierarchies. Is it generally not possible to use/import subdirectories or what's the problem?
go-version I used: go1.2.2 linux/amd64
Thanks for any advices
Your approach is completely wrong. Go has absolutely no concept of importing files or directories, all you can import in Go are packages. It now happens that the name of a package is it's path relative to GOPATH and you import packages by that name. But the identifier under which an imported package is available in the importing code depends on the package declaration of the package. You cannot simply "move" files between directories as each directory (for the go tool) is a single package without changing the package declaration.
You can have package x under path a/b/c. When you import package x with import ( "a/b/c" ) all the exported stuff from package x is available to you as x.ExportedName.
Please read http://blog.golang.org/organizing-go-code carefully.
Try and do a go build in a/b/d/e first, before trying to build in a/b: that will generate the compiled classes you want to import.
I am currently trying to publish a load of nuget packages for all the projects in this solution. The projects are setup in a simple tree, with Myre being the base project and everything depending on it:
Myre <- Myre.Debugging <- Myre.Debugging.UI <- Myre.UI
Myre <- Myre.UI
Myre <- Myre.Entities <- Myre.Graphics
I'm trying to package up each separate project as a nuget package with the correct dependencies on the other Myre subproject packages as necessary.
My first step was to make a package for Myre (nuspec and bat file of process). This seems to work nicely, the gallery shows Myre as having a ninject (another nuget package) dependency and all is well.
The problem comes when I tried to make the next package. Myre.Debugging depends upon Myre (with a normal project reference) and nothing else. Using this nuspec with nuget pack (verbose) gives:
Attempting to build package from '(x86) Myre.Debugging.csproj'.
Packing files from 'C:\Long_Path\Myre\Myre.Debugging\bin\x86\Release'.
Add file 'C:\Long_Path\Myre\Myre.Debugging\bin\x86\Release\Myre.Debugging.dll' to package as 'lib\net40-Client\Myre.Debugging.dll'
Add file 'C:\Long_Path\Myre\Myre\bin\x86\Release\Myre.dll' to package as 'lib\net40-Client\Myre.dll'
Add file 'C:\Long_Path\Myre\Myre\bin\x86\Release\Myre.XML' to package as 'lib\net40-Client\Myre.XML'
Found packages.config. Using packages listed as dependencies
Id: Myre.Debugging
Version: 1.0.0.2
Authors: Microsoft
Description: Description
Dependencies: Ninject (= 3.0.1.10)
Added file 'lib\net40-Client\Myre.Debugging.dll'.
Added file 'lib\net40-Client\Myre.dll'.
Added file 'lib\net40-Client\Myre.XML'.
Successfully created package 'C:\Long_Path\Myre\Myre.Debugging\Myre.Debugging.1.0.0.2.nupkg'.
As you can see it picks up a packages.config file (presumably from Myre since there isn't one here) which it then determines a Ninject dependency from. If I wanted Myre.Debugging and Myre to be a single package that would be fine. However this is not what I want, I want Myre.Debugging to pick up a dependency on the Myre package.
How can I setup nuget to use Myre as a package reference and not simply to copy the Myre assemblies into the Myre.Debugging package?
Edit:: I tried not using -IncludeReferencedProjects and specifying:
<dependencies>
<dependency id="Myre" version="1.0.0.1" />
</dependencies>
But for some reason this just creates a package with no dependencies at all! Even if manually specifying dependencies like this did work, it's hardly ideal.
According to the NuGet command line reference for the Pack command, the IncludeReferencedProjects switch works as follows:
Include referenced projects either as dependencies or as part of the package. If a referenced project has a corresponding nuspec file that has the same name as the project, then that referenced project is added as a dependency. Otherwise, the referenced project is added as part of the package.
In your case, Myre.Debugging.nuspec does not match the project file names: (x86) Myre.Debugging.csproj, etc. I suspect that you'll need to match up those file names to get that command line option to work.
Alternatively, if you want to get this to work with a <dependencies> element in your nuspec file, you may be facing another variant on the name mismatch problem. Your Myre.nuspec file defines its ID as follows:
<id>$id$</id>
The NuSpec reference says that the $id$ token is replaced by "The Assembly name." If it's talking about the name of the DLL (ignoring the extension), then I think the generated IDs will be (x86) Myre, etc. You might want to try hard-coding the ID temporarily just to see if that resolves the issue.
I haven't tried making these suggested changes, and I can't guarantee they will work, but I hope this points you in the right direction. Good luck!