I have created some local libraries in my dart lib directory.
These libraries are visible in dart packages for each newly created folder in the web directory. However, when I attempt to access them using the dart's package nomenclature eg package:reg/name.dart, the system always generates an error.
I think I am missing something.
I have read http://pub.dartlang.org/doc/package-layout.html but this did not help me either.
You need to ensure that the name you're using as the package matches that in pubspec.yaml.
Eg. if in pubspec.yaml you havename: my_app and your file is at lib\my_library.dart then you need to use import 'package:my_app/my_library.dart';.
Related
I want to compile uic to PySide6 but I don't find how to install pyside6-uic tool. Where can I install pyside6-uic? I downloaded PySide6 but command pyside6-uic doesn't work.
There is a reference here in the title:
https://doc.qt.io/qtforpython/tutorials/basictutorial/uifiles.html#using-ui-files-from-designer-or-qtcreator-with-quiloader-and-pyside6-uic
Step 1. If you installed PySide6
a. In a venv then go to your venv's folder.
b. Globally then go to your python installation folder.
Step 2. Go to Lib then site-packages then PySide6.
Step 3. Copy uic.exe ( or uic if the file extension are hidden) create a folder called bin and paste what you've copied inside it.
To compile ui files from:
QtDesigner: From the top menu select Form -> View Python Code... then click on the save icon (floppy disk) from the newly opened window.
Command Prompt: pyside6-uic.exe mainwindow.ui > ui_mainwindow.py
PowerShell: pyside6-uic.exe mainwindow.ui -o ui_mainwindow.py
If you using virtual environment, when you install pyside6 with pip in the virtual environment there is a folder named Scripts there is the pyside6-uic.exe tool.
if you have install pyside6 globally in your system and you use visual studio code you can use the extension PySide2-vsc then when you installed you can go to preferences > settings and search the PySide2-vsc extension settings then look for the "Command to compile a .ui file into python". Then you can use that feature with right-click on .ui files.
I could solve this issue to add this Path to my %PATH% Variable on windows.
C:\Users\<YOUR_USER_PATH_NAME>\AppData\Roaming\Python\Python311\Scripts
The pyside6-uic tool is supposed to be installed automatically when installing the Python package.
Check if uic is in PATH
When using loadUiType, the Qt documentation (here) states that :
The internal process relies on uic being in the PATH. The pyside6-uic
wrapper uses a shipped uic that is located in the
site-packages/PySide6/uic, so PATH needs to be updated to use that if
there is no uic in the system.
But even then, I got the following error :
Cannot run 'pyside6-uic': "execvp: No such file or directory" -
Exit status QProcess::NormalExit ( 255 )
Check if 'pyside6-uic' is in PATH
For me, pyside6-uic was not located in site-packages/PySide6/uic. When reinstalling the module with pip, I noticed this message :
WARNING: The scripts pyside6-assistant, pyside6-designer, pyside6-genpyi,
pyside6-linguist, pyside6-lrelease, pyside6-lupdate, pyside6-rcc and pyside6-uic are
installed in '/Users/<user>/Library/Python/3.8/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning,
use --no-warn-script-location.
So make sure to add the right directory to your $PATH variable.
Once it's done, you will be able to use the pyside6-uic command to generate a Python class from a UI file :
pyside6-uic mainwindow.ui > ui_mainwindow.py
Loading a .ui from code
You can also load a .ui file from your code using either:
loadUiType (doc page) :
This function generates and loads a .ui file at runtime, and it
returns a tuple containing the reference to the Python class, and the
base class.
or QUiLoader (doc page):
enables standalone applications to dynamically create user interfaces
at run-time using the information stored in UI files or specified in
plugin paths
from PySide6.QtUiTools import QUiLoader
ui_file = QFile("mainwindow.ui")
ui_file.open(QFile.ReadOnly)
loader = QUiLoader()
window = loader.load(ui_file)
window.show()
Generally speaking, use absolute paths to access your UI files. Relative paths are susceptible to errors.
I've already used devtools to create my package skeleton, then added a bunch of R code, metadata, documentation, etc. I would like to use rstan within this package. I understand that rstan::rstan.package.skeleton creates a package skeleton to facilitate this. So what is the best practice for augmented an existing package with the structure necessary to use rstan from that package? Thank you.
I would say to use rstan.package.skeleton to create the skeleton in a temporary directory and then copy the relevant stuff it creates into the package you created by devtools. This would include
cleanup and cleanup.win in the root of the directory
the tools directory
the exec directory
the inst/chunks subdirectory
the src directory
the R/stanmodels.R file
the DESCRIPTION file in the root of the directory
For the DESCRIPTION file, you may just have to combine it by hand with whatever DESCRIPTION file you have currently.
I couldn't find answer to this in Dart documentation.
My application's server-side is driven by Spray and by convention static files are stored in /webapp folder. When I try to build Dart project I get following error
C:\work\externals\dart-sdk\bin\pub.bat build --mode=release
Your package must have a "web" directory, or you must specify the source directories.
How can I change it from web to webapp ? My pubspec.yaml looks like this
name: dart_spray_example
description: A sample Dart/Spray application
dependencies:
browser: any
Here is layout of my application right now
You just pass it as an additional argument.
pub build --mode=release webapp
but I would expect troubles doing it this way because only some top-level directory names are compliant with the pub package layout convention.
pub build --mode=release example
would be fine.
It might be easier to just use web as the source directory and move the generated output to webapp. I'm aware that this can cause problems during development but I would expect it to be easier to fix the development setup instead of the build setup.
Using frameworks like Angular and Polymer which make heavy use of transformers have a strong dependency on the package layout convention.
I want to make Dart app that has flexible deployment. It can be started as a web server or standalone app in browser as well. My directory structure:
bin
- httpserver.dart
lib
- commonlib.dart
web
- web.html
- web.dart
pubspec.yaml
I wanto start either httpserver.dart providing web's content or web.html directly in Chromium. I have troubles with the lib visibility from bin/httpserver.dart. using the "import 'package:prj/commonlib.dart'" does not work. But from the web.dart is works fine.
Please advice how to share libs among bin's and web's code. Or I should I make structure of dirs somehow different?
Note: there is no packages sub-dir in the bin directory created by pub get. I am using dart sdk 1.7.2.
Thank you, Ladislav.
In the bin directory there should be a packages symlink created automatically but it is not in subdirectories of prj/bin. If the symlink isn't created just create it manually.
The dart page http://pub.dartlang.org/doc/#adding-a-dependency describes how you can have a dart file (parser_test.dart) import files from its own package using the 'import "package:..." style of import. It seems to imply this is a good thing - better than using relative paths. This example shown is for a file in test which appears to be special. But, then why does it not make sense for importing same package lib files from a lib in the package. Maybe it does make sense, but if so the pub update does not make it convenient.
foo/
/lib/
foo_lib_1.dart
foo_lib_2.dart
src/
foo_lib_1/
foo_lib_1_impl.dart
foo_lib_2/
foo_lib_2_impl.dart
Assume foo_lib_2 uses foo_lib_1. There are two options for foo_lib_2.dart:
import "../foo_lib_1.dart";
import "packages:foo/foo_lib_1.dart";
My guess is the suggested approach is the first for any such import that resides under lib. The reason I think this is pub update seems to automagically provide a soft link in the packages folder of any of bin, test, or example to foo, like foo -> ../lib. Yet, it does not do the same for the packages folder in top level foo. This means to get the second type of import (i.e. the packages import) to work you need to add:
foo:
path: lib
to the dependencies of foo in the pubspec.yaml. Is there any advantage or disadvantage for a library to use the package style import to import another library (not in test, bin, or example) from its own package? Is there a reason for the apparent inconsistency?
After accepting the answer below, I still am not seeing it. Here is what I'm seeing in a shell session and I would like to reconcile this behavior with the answer. Any explanations appreciated. I am using emacs instead of DartEditor, thus the old-school command line approach here.
### Show all files, one dart library file and one yaml, plus empty
### lib and test folders
user#user-thinkpad:/tmp/uml_codegen_sample$ ls -R
.:
lib pubspec.yaml test
./lib:
plusauri.dart
./test:
### Show contents of pubspec
user#user-thinkpad:/tmp/uml_codegen_sample$ cat pubspec.yaml
name: domain_model
version: 0.0.1
description: >
Auto-generated support from /home/user/plusauri/modeling/plusauri.xmi.json
dependencies:
ebisu:
path: /home/user/open_source/codegen/dart/ebisu
### Run pub install and show the changes. Note there is a soft
### link to packages from test, but not lib.
user#user-thinkpad:/tmp/uml_codegen_sample$ pub install
Resolving dependencies...
Dependencies installed!
Some packages that were installed are not compatible with your SDK version 0.4.7+5.r21658 and may not work:
- 'pathos' requires >=0.5.0+1
You may be able to resolve this by upgrading to the latest Dart SDK
or adding a version constraint to use an older version of a package.
user#user-thinkpad:/tmp/uml_codegen_sample$ ls -R
.:
lib packages pubspec.lock pubspec.yaml test
./lib:
plusauri.dart
./packages:
domain_model ebisu pathos
./test:
packages
### Note here the program does not work, and suspiciously pub
### install put no packages link under lib like it did test
user#user-thinkpad:/tmp/uml_codegen_sample$ dart lib/plusauri.dart
Unable to open file: /tmp/uml_codegen_sample/lib/packages/ebisu/ebisu_utils.dart'file:///tmp/uml_codegen_sample/lib/plusauri.dart': Error: line 5 pos 1: library handler failed
import "package:ebisu/ebisu_utils.dart" as EBISU_UTILS;
^
### Copy the same dart file to test to show that it can run there
### just fine
user#user-thinkpad:/tmp/uml_codegen_sample$ cp lib/plusauri.dart test/
user#user-thinkpad:/tmp/uml_codegen_sample$ dart test/plusauri.dart
Main for library plusauri
user#user-thinkpad:/tmp/uml_codegen_sample$
### Finally, manually create the soft link in lib, to show it will
### then run
user#user-thinkpad:/tmp/uml_codegen_sample$ ln -s ../packages lib/packages
user#user-thinkpad:/tmp/uml_codegen_sample$ dart lib/plusauri.dart
Main for library plusauri
Actually, you can definitely import using the package:foo/foo_lib_1.dart syntax without needing to change your pubspec.yaml or even creating a pubspec.yaml in the first place!
You can see that this is true from a language level, in this test: https://github.com/dart-lang/bleeding_edge/blob/master/dart/tests/standalone/package/packages/package1.dart
and an example of this in the wild is: https://github.com/kevmoo/hop.dart/blob/master/lib/hop_tasks.dart#L17
I do not think there is any benefit from writing one way or another except that writing relative paths is slightly shorter.
From a project structure point of view, I would use relative path imports when I am drilling into subdirectories that are not going to be exposed to the user. src is generally seen as implementation specific details that won't be visible to external users, so use relative paths to your heart's content.
However, if you're working within multiple directories, then you should use package: imports to reinforce the idea that the parts are stand-alone and interchangeable. Within the lib directory itself, you want to say that these two libraries, although they might rely on each other, can live separately and are not bound by their physical location.
I would recommend not ever using ../ in your imports, as that is fragile and may break in strange ways if/when you modify directory structure or deploy.