armmbed / yotta Goto Github PK

e.g. instead of printing:

/Volumes/Work/synced/Dev/IoT/objc/libobjc2-svn/yotta_modules/foundation -> /usr/local/lib/yotta_modules/foundation -> /usr/local/lib/yotta_modules/foundation

for a broken symlink, it should print:

/Volumes/Work/synced/Dev/IoT/objc/libobjc2-svn/yotta_modules/foundation -> /usr/local/lib/yotta_modules/foundation -> BROKEN

And why not use colours to make it obvious, too.

In the package.json file, dependency statements with invalid syntax produces unhandled python exception (see below) instead of outputting more informative error messages.

Traceback (most recent call last):
  File "/usr/local/bin/yt", line 9, in <module>
    load_entry_point('yotta==0.0.18', 'console_scripts', 'yt')()
  File "/Library/Python/2.7/site-packages/yotta/main.py", line 87, in main
    status = args.command(args)
  File "/Library/Python/2.7/site-packages/yotta/link.py", line 51, in execCommand
    dropSudoPrivs(lambda: install.execCommand(args))
  File "/Library/Python/2.7/site-packages/yotta/link.py", line 30, in dropSudoPrivs
    r = fn()
  File "/Library/Python/2.7/site-packages/yotta/link.py", line 51, in <lambda>
    dropSudoPrivs(lambda: install.execCommand(args))
  File "/Library/Python/2.7/site-packages/yotta/install.py", line 31, in execCommand
    installDeps(args)
  File "/Library/Python/2.7/site-packages/yotta/install.py", line 63, in installDeps
    available_components = [(c.getName(), c)]
  File "/Library/Python/2.7/site-packages/yotta/lib/component.py", line 426, in satisfyDependenciesRecursive
    provider = provider
  File "/Library/Python/2.7/site-packages/yotta/lib/component.py", line 266, in __getDependenciesRecursiveWithProvider
    provider = provider
  File "/Library/Python/2.7/site-packages/yotta/lib/component.py", line 174, in __getDependenciesWithProvider
    satisfyDep, self.getDependencySpecs(target)
  File "/Library/Python/2.7/site-packages/yotta/lib/component.py", line 167, in satisfyDep
    update_installed
  File "/Library/Python/2.7/site-packages/yotta/lib/component.py", line 413, in provider
    r = access.satisfyVersionByInstalling(name, version_req, working_directory)
  File "/Library/Python/2.7/site-packages/yotta/lib/access.py", line 211, in satisfyVersionByInstalling
    return _satisfyVersionByInstallingVersion(name, version_required, install_into, v)
  File "/Library/Python/2.7/site-packages/yotta/lib/access.py", line 219, in _satisfyVersionByInstallingVersion
    assert(version)
AssertionError

We may eventually need to support a SHA (or similar) checksum in the yotta package metadata, and/or GPG signatures by the "owner". Not a priority right now, but maybe something to consider for the package.json schema.

Think I prefer testDependencies – the usage is quite different to npm's devDependencies.

This would let you easily push fixes to a dependency.
If the source URL is a github one, it should also create a fork of the repo for you, if you don't have one already.

npm does this (and you have to do this for anything to be able to use the link since shared dependencies may be resolved into the yotta_modules of the linked package), so yotta should.

Title.

Workaround:

• Create personal access token on Github
• insert in file .yotta/config:

[github]
user = username
authtoken = personal_access_token

Currently if yotta is interrupted then partially-unpacked modules can be left in place, causing build errors.

When yotta writes cmakelists files it shouldn't touch files that haven't changed.

The CMakeLists should pick up new files automatically (use globs).

This will require a question about whether the component is an application or a library – to determine whether the CMakeLists should add_library or add_executable.

(as title) You can't unlink linked packages (easily).

There's a problem when yt install is run on more than one computer when the same github username and password are used, as github complains that OAuth Tokens already exist. I'm not sure whether a fix is possible, and a work around is just to delete the keys in user settings on Github, however it would be nice to just work.

If dependencies of the current component depend on the current component, install, update and build fail because they use/install a duplicate of the current component.

running yotta test should run ctest in the build/$TARGET/test directory

Currently only individual access modules know how to parse these specs, that either needs exposing or re-implementing.

(as there is no library to link against)

The best solution for this is probably to auto generate a dummy library when we're auto generating CMakeLists and find no source files.

While I was trying to get yotta work on my Macbook Pro, when I do yt install, it shows this error

Enter the password for github user dorafmon:
Traceback (most recent call last):
File "/usr/local/bin/yt", line 9, in
load_entry_point('yotta==0.0.21', 'console_scripts', 'yt')()
File "build/bdist.macosx-10.9-x86_64/egg/yotta/main.py", line 87, in main
File "build/bdist.macosx-10.9-x86_64/egg/yotta/install.py", line 31, in execCommand
File "build/bdist.macosx-10.9-x86_64/egg/yotta/install.py", line 63, in installDeps
File "build/bdist.macosx-10.9-x86_64/egg/yotta/lib/component.py", line 438, in satisfyDependenciesRecursive
File "build/bdist.macosx-10.9-x86_64/egg/yotta/lib/component.py", line 281, in __getDependenciesRecursiveWithProvider
File "build/bdist.macosx-10.9-x86_64/egg/yotta/lib/component.py", line 189, in __getDependenciesWithProvider
File "build/bdist.macosx-10.9-x86_64/egg/yotta/lib/component.py", line 182, in satisfyDep
File "build/bdist.macosx-10.9-x86_64/egg/yotta/lib/component.py", line 427, in provider
File "build/bdist.macosx-10.9-x86_64/egg/yotta/lib/access.py", line 209, in satisfyVersionByInstalling
File "build/bdist.macosx-10.9-x86_64/egg/yotta/lib/access.py", line 79, in latestSuitableVersion
File "build/bdist.macosx-10.9-x86_64/egg/yotta/lib/github_access.py", line 189, in availableVersions
File "build/bdist.macosx-10.9-x86_64/egg/yotta/lib/github_access.py", line 59, in wrapped
File "build/bdist.macosx-10.9-x86_64/egg/yotta/lib/github_access.py", line 127, in authorizeUser
File "/usr/local/lib/python2.7/site-packages/restkit/resource.py", line 144, in post
headers=headers, params_dict=params_dict, **params)
File "/usr/local/lib/python2.7/site-packages/restkit/resource.py", line 210, in request
response=resp)
restkit.errors.RequestFailed: {"message":"Validation Failed","documentation_url":"https://developer.github.com/v3/oauth_authorizations/#create-a-new-authorization","errors":[{"resource":"OauthAccess","code":"already_exists","field":"description"}]}

I assume this is because I have an Oauth token installed for my Mac mini so I am not allowed to have another one, right?

For example, if a dependency is linked at the top level, but not depended on directly by the top-level component, then list doesn't display it.

i.e.: name/repo#branchname name/repo#tag or name/repo@tagname (and possibly name/repo@branchname) instead of just name/repo@version.

This will require versions & specifications that can wrap arbitrary strings when they don't parse as actual semantic versions.

bobbys-air:frdm_gpio 16.49.33 taylorr$ yotta link-target frdm-k64f
info: /Users/taylorr/Desktop/frdm_gpio 16.49.33/yotta_targets/frdm-k64f -> /usr/local/lib/yotta_targets/frdm-k64f -> /Users/taylorr/Code/GitHub/target-frdm-k64f
bobbys-air:frdm_gpio 16.49.33 taylorr$ yotta target frdm-k64f
bobbys-air:frdm_gpio 16.49.33 taylorr$ yotta build
error: The current directory does not contain a valid module.
bobbys-air:frdm_gpio 16.49.33 taylorr$ yotta init
Enter the module name:
Enter the initial version: <0.0.0>
Short description:
Keywords: <>
Author:
Repository url:
Homepage:
What is the license for this project (ISC, MIT, Apache-2 etc.)?
Is this module an executable? yes
Traceback (most recent call last):
File "/usr/local/bin/yotta", line 9, in
load_entry_point('yotta==0.0.28', 'console_scripts', 'yotta')()
File "/usr/local/lib/python2.7/site-packages/yotta/main.py", line 117, in main
status = args.command(args)
File "/usr/local/lib/python2.7/site-packages/yotta/init.py", line 132, in execCommand
c.writeDescription()
File "/usr/local/lib/python2.7/site-packages/yotta/lib/pack.py", line 167, in writeDescription
self.vcs.markForCommit(self.description_filename)
File "/usr/local/lib/python2.7/site-packages/yotta/lib/vcs.py", line 171, in markForCommit
self.repo.hg_add(os.path.join(self.worktree, relative_path))
File "/usr/local/lib/python2.7/site-packages/hgapi/hgapi.py", line 144, in hg_add
self.hg_command("add", filepath)
File "/usr/local/lib/python2.7/site-packages/hgapi/hgapi.py", line 118, in hg_command
return Repo.command(self.path, self._env, *args)
File "/usr/local/lib/python2.7/site-packages/hgapi/hgapi.py", line 89, in command
stdout=PIPE, stderr=PIPE, env=env)
File "/usr/local/Cellar/python/2.7.7_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 710, in init
errread, errwrite)
File "/usr/local/Cellar/python/2.7.7_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 1327, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

Currently the 403 (permission denied) causes a re-auth attempt with github. That's wrong.

Should check the owner first. In fact, the registry (and client) should check that the owner in the package/target description is the person who's publishing.

This is probably just a case of me misunderstanding, but yotta probably shouldn't install the test/ directory to site-packages. Obviously pip knows these files are owned by yotta, but none the less... and it's confusing to have a directory called "test" in site-packages that does not correspond to the Python-internal regression test module (https://docs.python.org/2/library/test.html).

/usr/local/lib/python2.7/site-packages/test$ ls
__init__.py      download.py      hg_access.py     vcs.py
blobs.py         git_access.py    registry.py      versions.py
components.py    github_access.py validation.py

Possibly components should specify the name of libraries they export in their package description.

yotta could then maintain a YOTTA_LINK_DEPENDENCIES variable with the names of the components that the current component depends on.

Challenge of this is dealing with yotta components that don't export a library at all.

It should install the same way as a "natural" dependency would.

I got an error installing ARM-RD/libobjc2, but when I fixed the underlying issue and re-ran yotta install, it just said

info: [email protected]

instead of attempting re-install (so I guess it thought it was already complete?). I had to delete yotta_modules/ to force it to re-install.

It should be possible for 'yotta build' to propagate some command line arguments to 'make' (such as '-j' for parallel builds and 'VERBOSE=1' to see what make is actually executing)

There is almost no reason not to, since we don't load debug sections onto the device, and it's a pain when you forget to add -d while building.

Example, the UIKit module depends on yottos-platform version 0.2.1 or higher, which Yotta enforces with this line in the dependency list:

"yottos-platform": "ARM-RD/yottos-platform >=0.2.1"

However, when UIKit is included in modules that also includes yottos-platform (through other modules) the version requirement is ignored if yottos-platform is already installed.

Workaround:
Manually tweak the dependency list in module.json to install modules in the right order.

Should be able to do something like:
$ yotta login headlessme
> Enter password:

and

$ yotta logout

Title.

When doing 'yt publish', Yotta should first install the module candidate in a clean directory and do a 'yt install' and 'yt build' on it. Only if the build is successful should the module be uploaded to the registry.

checking out a fresh project you should be able to do yotta build and it will run the install step to grab dependencies for you

bobbys-air:frdm_gpio 16.49.33 taylorr$ yotta build
info: generate for target: frdm-k64f 0.0.1 at /Users/taylorr/Desktop/frdm_gpio 16.49.33/yotta_targets/frdm-k64f
CMake Error at /usr/local/Cellar/cmake/3.0.0/share/cmake/Modules/CMakeDetermineSystem.cmake:104 (message):
Could not find toolchain file:
/Users/taylorr/Desktop/frdm_gpio;16.49.33/yotta_targets/frdm-k64f/CMake/toolchain.cmake
Call Stack (most recent call first):
CMakeLists.txt:21 (project)

CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_C_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_C_COMPILER
CMake Error: Could not find cmake module file: /Users/taylorr/Desktop/frdm_gpio 16.49.33/build/frdm-k64f/CMakeFiles/3.0.0/CMakeCCompiler.cmake
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER
CMake Error: Could not find cmake module file: /Users/taylorr/Desktop/frdm_gpio 16.49.33/build/frdm-k64f/CMakeFiles/3.0.0/CMakeCXXCompiler.cmake
CMake Error at CMakeLists.txt:21 (project):
No CMAKE_C_COMPILER could be found.

Tell CMake where to find the compiler by setting the CMake cache entry
CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name
if it is in the PATH.

CMake Error at CMakeLists.txt:21 (project):
No CMAKE_CXX_COMPILER could be found.

Tell CMake where to find the compiler by setting the CMake cache entry
CMAKE_CXX_COMPILER to the full path to the compiler, or to the compiler
name if it is in the PATH.

CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
error: command ['cmake', '-D', 'CMAKE_BUILD_TYPE=Debug', '-G', 'Unix Makefiles', '.'] failed
bobbys-air:frdm_gpio 16.49.33 taylorr$ ls /Users/taylorr/Desktop/frdm_gpio;16.49.33/yotta_targets/frdm-k64f/CMake/toolchain.cmake
ls: /Users/taylorr/Desktop/frdm_gpio: No such file or directory
-bash: 16.49.33/yotta_targets/frdm-k64f/CMake/toolchain.cmake: No such file or directory

If you do

npm install some-package --save

then it patches your package.json to include the new dependency (marked with the ~ semver modifier, like ~0.1.2).

Either targets need to always respect the CC/CXX environment variables, so that we can use scan-build to run the clang static analyser (they probably should anyway), or we need to expose another way for targets to provide static analysis support – and yotta should run this by default as part of building, if it is available on a specific target.

This should probably just print a message saying they don't have access if they are logged in, but direct them to the login flow if they're not. Should be able to tell the different by the response code from the registry (401 vs 403 I think)

When installing Yotta with Pip, it leaves a "src" directory lying around afterwards, containing "pip-delete-this-directory.txt" and the Yotta source code. If you follow the instructions (which note that the "src" directory is an installation artefact that can be deleted) and go ahead and delete this directory, yotta no longer works. If nothing else, the instructions should be updated to put that directory somewhere sensible and not that you're not actually supposed to follow the deletion instructions.

(I'm using brew python and pip, not system python and manually-installed pip).