I have my native application, which we want to change into flutter. For that, we have decided to build multiple flutter modules and add that to the existing native application. I am not sure whether flutter support building multiple modules in a single native application.
Also in the future, as we want to move away from native completely, I didn't find any solution where we can build a fresh flutter application using already developed flutter modules.
It is possible. What you can do is create modules (packages) somewhere in your project, for example, create a directory modules and place them there.
.
├── modules
│ ├── module1
│ ├── module2
│ ├── module3
│ └── module4
To add them to the current project, in your pubspec.yaml, you can do the following:
dependencies:
# ...
module1:
path: ./modules/module1
# ... etc for other modules
These local modules are called path dependencies.
Related
Problem statement
When building a Python package I want the build tool to automatically execute the steps to generate the necessary Python files and include them in the package.
Here are some details about the project:
the project repository contains only the hand-written Python and YAML files
to have a fully functional package the YAML files must be compiled into Python scripts
once the Python files are generated from YAMLs, the program needed to compile them is no longer necessary (build dependency).
the hand-written and generated Python files are then packaged together.
The package would then be uploaded to PyPI.
I want to achieve the following:
When the user installs the package from PyPI, all necessary files required for the package to function are included and it is not necessary to perform any compile steps
When the user checks-out the repository and builds the package with python -m build . --wheel, the YAML files are automatically compiled into Python and included in the package. Compiler is required.
When the user checks-out the repository and installs the package from source, the YAML files are automatically compiled into Python and installed. Compiler is required.
(nice to have) When the user checks-out the repository and installs in editable mode, the YAML files are compiled into Python. The user is free to make modifications to both generated and hand-written Python files. Compiler is required.
I have a repository with the following layout:
├── <project>
│ └── <project>
│ ├── __init__.py
│ ├── hand_written.py
│ └── specs
│ └── file.ksc (YAML file)
└── pyproject.toml
And the functional package should look something like this
├── <project>
│ └── <project>
│ ├── __init__.py
│ ├── hand_written.py
│ └── generated
│ └── file.py
├── pyproject.toml
└── <other package metadata>
How can I achieve those goals?
What I have so far
As I am very fresh to Python packaging, I have been struggling to understand the relations between the pyproject.toml, setup.cfg and setup.py and how I can use them to achieve the goals I have outlined above. So far I have a pyproject.toml with the following content:
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"
[project]
name = "<package>"
version = "xyz"
description = "<description>"
authors = [ <authors> ]
dependencies = [
"kaitaistruct",
]
From reading the setuptools documentation, I understand that there are the build commands, such as:
build_py -- simply copies Python files into the package (no compiling; works differently in editable mode)
build_ext -- builds C/C++ modules (not relevant here?)
I suppose adding the compile steps for the YAML files will involve writing a setup.py file and overwriting a command, but I don't know if this is the right approach, whether it will even work, or if there are better methods, such as using a different build backend.
Alternative approaches
A possible alternative approach would be to manually compile the YAML files prior to starting the installation or build of the package.
My flutter project depends on several local flutter and dart packages to keep things separated and clean.
My folder structure is like this:
main-flutter-project
│ lib
| test
│ pubspec.yaml
│
└── local-packages
│ └── dart-package-1
│ │ pubspec.yaml
│ │
│ └── flutter-package-1
│ │ pubspec.yaml
│ │
│ └── flutter-package-2
│ pubspec.yaml
...
Each local package is self contained and can be maintained without touching the main project.
This structure means that I have many pubspec.yaml files where I have to keep the dependencies updated.
When I use e.g. the bloc libaray bloc: ^7.2.1 in say 5 packages, I have to update the version in each pubspec file separately when a new version is released.
Is there a possibility to specify those shared package dependency versions in only one place where the other pubspec.yaml files refer to?
I've seen this e.g. with Maven where you can specify a property <junit.version>4.12</junit.version> and access it from somewhere else <version>${junit.version}</version>.
We were solving a similar problem.
AFAIK, there's no built-in or recommended way to do this, so we were inventing some hacks.
In our case, we have core package that has some shared functionality and common dependencies, if you don't have it, you can still create an artificial one, let's say, shared_dependencies package, and specify all the shared dependencies there.
Now, let's say, package foo depends on shared_dependencies package, and there's dependency bar defined in shared_dependecies package that foo needs to use. There are some ways to do that:
Import dependency directly. Since foo depends transitively on bar, you can just write import package:bar/bar.dart and it will work. It's not the best way though:
it's bad practice to import transitive dependency (there's even a linter rule for that);
auto-import won't work;
Export package in shared_dependencies package. I.e. shared_dependencies.dart can contain the following lines:
export 'package:bar/bar.dart'
That means that in your foo package you can just write import 'shared_dependencies/shared_dependencies.dart' and get access to bar content.
Pros:
auto-imports work.
Contras:
if you export several packages, there can be name conflicts (you'll have to hide some names in export);
if foo package depends on one bar package only, it could be weird to import all shared_dependencies.
Export in separate libraries of shared_dependencies package. You can group some related packages together in different files, e.g.:
bar.dart:
export 'package:bar/bar.dart'
bloc.dart:
export 'package:bloc_concurrency/bloc_concurrency.dart';
export 'package:flutter_bloc/flutter_bloc.dart';
In that case, if you need bar package in foo, you write import 'package:shared_dependencies/bar.dart'; if you need bloc, you write import 'package:shared_dependencies/bloc.dart'. Auto-imports work as well.
Add direct dependency to foo package, but don't specify version constraints:
bar:
This basically means that you need any bar package, but since foo also depends on shared_dependencies, its constraints will be taken into account. This may be needed if you're using some executables from bar package, as there's a limitation in Dart SDK that doesn't allow to run executables in transitive dependencies.
In our project, we ended up using 2 for the most commonly used packages, 3 for other packages, and 4 for packages with executables that we need to run.
I have used vscode 1.41.1 on my mac for a few months and it worked good until I started to use go modules for dependency management. At the moment I am rewriting a simple tool and introduce packages for separate functionalities.
My code structure looks like this:
├── bmr.go -> package main & main(), uses below packages
├── check
│ ├── check.go -> package check
│ └── check_test.go
├── go.mod
├── go.sum
├── push
│ ├── push.go -> package push
│ └── push_test.go
└── s3objects
├── s3objects.go -> package s3objects
└── s3objects_test.go
My go.mod file:
module github.com/some-org/business-metrics-restore
go 1.13
require (
github.com/aws/aws-sdk-go v1.28.1
github.com/go-redis/redis v6.15.6+incompatible
github.com/sirupsen/logrus v1.4.2
github.com/spf13/viper v1.6.1
github.com/stretchr/testify v1.4.0
golang.org/x/sys v0.0.0-20200113162924-86b910548bc1
)
All is fine when I invoke go test/run/build commands from the shell. But when I use 'Debug' -> 'Run Without Debugging' I get:
go: finding github.com/some-org/business-metrics-restore/push latest
go: finding github.com/some-org/business-metrics-restore latest
go: finding github.com/some-org/business-metrics-restore/check latest
go: finding github.com/some-org/business-metrics-restore/s3objects latest
build command-line-arguments: cannot load github.com/some-org/business-metrics-restore/check: module github.com/some-org/business-metrics-restore#latest found (v0.0.0-20191022092726-d1a52439dad8), but does not contain package github.com/some-org/business-metrics-restore/check
Process exiting with code: 1
My code currently is in a feature branch and d1a52439dad8 is the first (init) and only commit on master. No code for the tool (incl. 3 mentioned non main packages) is in the master branch.
The problem here is that for some reason as you see above vscode fetches state from master and I cannot override this behaviour.
Can anyone help me?
Thanks!
Best Regards,
Rafal.
I realized that if the go.mod is not at the root of your project VSCode does not work properly. I have an AWS SAM project with the following structure:
├── Makefile
├── README.md
├── nic-update
│ ├── go.mod
│ ├── go.sum
│ ├── main.go
│ ├── main_test.go
│ └── r53service
│ └── r53.go
├── samconfig.toml
└── template.yaml
and the only way it works if by starting VSCode from the nic-update directory.
My go.mod has the following content:
require (
github.com/aws/aws-lambda-go v1.13.3
github.com/aws/aws-sdk-go v1.32.12
)
module github.com/jschwindt/ddns-route53/nic-update
go 1.14
I realized that if the go.mod is not at the root of your project VSCode does not work properly
That might now (Oct. 2020) be supported, as a consequence of gopls v0.5.1 and its experimental feature Multi-module workspace support from the proposal 32394.
Even if you don't have multiple modules, a go.mod in a sub-folder (instead of the root folder of your project) will be better managed (if you activate the gopls.experimentalWorkspaceModule setting).
As noted by kayochin in the comments:
The setting should be "gopls": {"build.experimentalWorkspaceModule": true}
See the documentation "gopls / Settings / experimentalWorkspaceModule bool".
I have also had trouble with VS Code and modules. The current status of VS Code support for Go Modules is kept up to date here: https://github.com/golang/vscode-go#Set-up-your-environment
In that link they suggest ditching most of the existing extensions VS Code encourages you to install with Go and instead using the language server gopls with these directions:
Add the below in your settings to use it.
"go.useLanguageServer": true
Note: You will be prompted to install the latest stable version of gopls as and when the Go tools team tag a new version as stable.
You should also fix autoimporting:
Add the setting "go.formatTool": "goimports" and then use Go: Install/Update Tools to install/update goimports as it has recently added support for modules.
When you do these things, keep in mind that you'll also lose a couple of features:
Completion of unimported packages doesnt work
Find references and rename only work in a single package
I'm starting to learn Ionic2, I have create a new empty project with ionic start myproject blank --v2 and everything works correctly if I do ionic serve.
Then I read this tutorial and many others. All of them state that the ionic folder structure should have an app folder:
If I look at my project folder structure I can't see any app folder. My structure looks so:
.
├── hooks
├── plugins
├── scss
├── www
│ ├── index.html
│ ├── css
│ ├── img
│ ├── js
│ └── lib
├── bower.json
├── config.xml
├── gulpfile.js
├── ionic.project
└── package.json
Now I'd like to follow this tutorial in order to build my first application but as you can see the folder structure of that example is different from mine and as an Ionic beginner I'm a little confused.
FIY (if it matters):
I'm referring to this page for the templates.
cordova -v: 6.2.0
ionic -v: 1.7.15
It might because your Node.js needs update.
First use node --version in your terminal (if you use Mac) to check the version of your Node.js. I had the same problem with you when node version in my Mac was v5.10.1 and solved it by using brew upgrade node to upgrade my Node.js to v6.3.1.
After updating your Node.js to the latest version just use ionic start myProject --v2 to create a new project and then the new project you created should have /app inside.
PROBLEM:
When I'm working with a Scala Play 2.0.4 application from within IntelliJ IDEA 12, I'm getting a lot of red syntax highlighting errors that don't show up as errors when I run the application from within Play! at the command line.
QUESTION:
Are there others who are successfully running Scala Play 2.0 applications from within IntelliJ IDEA 12? If so, can you give me some suggestions as to how I might do this as well.
BACKGROUND INFO:
When I create a new project within IntelliJ, I set Play 2 home to ~/bin/opt/play-2.0.4, it creates the project and then a dialog box appears titled "Project Files Changed" which says that "Project file .../.idea/misc.xml has been changed externally. It is recommended to reload project for changes to take effect." If I ignore the prompt to reload the project, and I ctl-ins on app/, I get the following options:
Java Class
Scala Class
File
Package
I then create a package 'models', and a scala file 'Models.scala' with the code shown below, 'Hello' is syntax-highlighted as red and when I hover over the code, IDEA indicates that it can't find 'Hello' within the object MyDB:
package models
case class Hello(id: Int, name: String)
object MyDB {
val hellos: List[Hello] = List(Hello(1, "Foo"), Hello(2, "Bar"))
}
I can now create create app/models/Models.scala with the code above and there are no highlighting errors. However, when I go to project settings -> Modules -> Dependencies, it says that 'sbt-and-plugins' has a broken path and "Module 'untitled': invalid item 'scala-2.9.1' in the dependencies list"
On the other hand, if I click 'ok' to reload the project for the changes to take effect, then if I I ctl-ins on app/, I get the following options:
File
Directory
This second option occurs also if I generate idea from within play at the command line (as well, with-sources), and also if I compile the project (either before or after I run idea).
As a further hint the app directory is colored blue if I don't reload the project, but once I reload it, then the app directory icon is brownish (like the others).
It is the same whether I use play-2.0.4 that I downloaded myself or whether I ask IntelliJ to download it when I create the new project. It also is the same whether I have the playframework with Play 2.0 Support or just the Play 2.0 Support by itself.
For further information, I'm running Arch Linux, Oracle Java 1.7.0_09, scala-2.9.1.final, Play 2.0.4, IntelliJ 12.0 IU-123.72. Plugins: Scala (0.6.371), Play 2.0 Support (0.1.86), Playframework Support (both with and without this, I get the same error).
UPDATE:
Here's the stacktrace http://pastebin.com/uWEpv5Gd, which shows that IDEA throws an exception when creating the project, as follows:
[ 87553] ERROR - com.intellij.ide.IdeEventQueue - Error during dispatching of java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=com.intellij.openapi.progress.util.ProgressWindow$MyDialog$1#3b5a26d6,notifier=null,catchExceptions=false,when=1355073846201] on sun.awt.X11.XToolkit#1bd172ba
I usually to the following to get Play projects running in IntelliJ 12:
Create the project from the terminal with play new "projectname"
Go into the new folder "projectname"
Run play idea
Open that folder with IntelliJ and enable syntax highlighting
Hope this helps
The problem was not the JVM, the problem is with the Play 2.0 plugin. I tested it with various JVMs in 1.7 and 1.6 and was still getting the same problem. I tried a fresh install of Intellij IDEA 12 by deleting the configuration directory, and it was doing the same thing. When I create a new project with IDEA 12, here's what the directory structure of target looks like:
[ambantis#okosmos target]$ tree
.
├── scala-2.9.1
│ └── cache
│ └── update
│ ├── inputs
│ └── output
└── streams
└── $global
├── ivy-configuration
│ └── $global
│ └── out
├── ivy-sbt
│ └── $global
│ └── out
├── project-descriptors
│ └── $global
│ └── out
└── update
└── $global
└── out
13 directories, 6 files
what's missing are /target/scala-2.9.1/classes and /target/scala-2.9.1/classes_managed. The solution is as follows:
After the build process, if you see a dialog box that says, "Project Files Changed", like this:
do not click OK, instead escape. Then open the play console and compile the application. At this point it will work. You will only see errors that there are unused jar files, but otherwise everything will work fine.