I use the pip install c:\path\to\project command to install my local package from a pyproject.toml configuration. It works fine and I can also uninstall the package with pip uninstall project. The only thing that makes me unhappy is the project folder being polluted with two extra folders: build & project.egg-info. The same happens when I try to build it with python -m pip wheel . -w .dist. Is there any way to suppress or modify this behavior and keep the project folder clean?
project
|- pyproject.toml
|- project/
| | - test.py
|- build/ <-- extra folder
|- project.egg-info/ <-- extra folder
Related
Suppose I have a monorepo using the standard workspace structure:
monorepo
|- package.json
|- yarn.lock
|- packages
|- package_a
|- package_b
I want to completely get rid of package_a while also updating the yarn.lock accordingly.
The following doesn't update the lockfile:
$ rm -rf packages/package_a
$ yarn install
Running this in the root of the monorepo doesn't work either:
$ yarn remove -W package_a
error This module isn't specified in a package.json file.
This does work, but bumps all packages where the range allows which is not desired.
$ rm -rf packages/package_a
$ yarn upgrade
How can I accomplish this?
I may misunderstand your question... But it appears that you need to include each package in your package.json as mentioned with each workspace here: https://classic.yarnpkg.com/en/docs/workspaces/.
Needed in package.json:
{
"private": true,
"packages": ["package_a", "package_b"]
}
I'm guessing this is why you are getting the error error This module isn't specified in a package.json file. when attempting yarn remove -W package_a. When it is included in the package.json then just yarn remove package_a this will also update your yarn.lock automatically.
https://classic.yarnpkg.com/en/docs/cli/remove
I just started writing Go today (so 0 experience), and wonder if Go supports any form of "building all source files" like what mvn install does.
My project structure is
src
`-github.com
`-myproject
|- package1
| `- main.go
`- package2
|- lib1_used_by_main.go
`- lib2_used_by_main.go
When I do
cd src/github.com/myproject
go build
this fails with no buildable Go source files in src/github.com/myproject, which is kind of right, because all source files are in subpackages.
Is there a command to build all subpackages, without listing each of them explicitly?
After you cd to the base directory, use go build ./... Note that there are 3 periods as it is an ellipsis. This will recursively build all subdirectories. Of course you can always do go build path/to/my/base/... from wherever without needing to cd to the directory.
This is very useful for those who use an IDE that relies on the go/pkg directory, such as SublimeText3 with GoSublime. Making changes to a dependency package won't update the autocompletes until you build the package, which places it in the go/pkg directory.
My own projects are broken into a multiple package structure, so I frequently have to go build ./... to update my autocompletion.
I have installed Composer on Ubuntu server using the global command. I have two folders named folder1 and folder2; both of them have their own composer.json files.
I want to install a package in only a folder. What happens after I edit the required composer.json file and I run composer install?
The dependencies will be installed into the current project directory.
When you run composer install, Composer will read the composer.json file from the current directory and then resolve the dependencies you defined and finally install them into a vendor subfolder.
See https://getcomposer.org/doc/03-cli.md#install
folder1
|- composer.json // <-- dependency "VendorA/PackageA"
|- vendor
|- composer
|- VendorA // <-- lands here after "composer install"
|- PackageA
folder2
|- composer.json // <-- dependency "VendorB/PackageB"
|- vendor
|- composer
|- VendorB // <-- lands here after "composer install"
|- PackageB
I currently developing an interface for a library as a GNU Octave package. Normally packages in GNU Octave are installed via
pkg install tarball_of_the_package.tar.gz
But compressing the package for each test is more or less time consuming. Now my question is if it is possible to call somehow the pkg install mechanism from a directory which has a valid package structure like in the tarball? Running
pkg install .
from inside this directory yields an error:
unpack: FILETYPE must be "gunzip" for a directory
Even specifying the whole path as
pkg install /path/to/the/package/source
results in the same problem.
At the moment I am using GNU Octave 4.0.0 for my developments.
What most packages have is a Makefile at the root of the package with targets such as install that will handle that for you. See for example the Makefile for the statistics package which allow you to do:
$ hg clone http://hg.code.sf.net/p/octave/statistics
destination directory: statistics
requesting all changes
adding changesets
adding manifests
adding file changes
added 401 changesets with 996 changes to 172 files
updating to branch default
133 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd statistics/
$ make install
Creating package version 1.2.4 release ...
rm -rf "statistics-1.2.4"
hg archive --exclude ".hg*" --exclude "Makefile" --type files "statistics-1.2.4"
chmod -R a+rX,u+w,go-w "statistics-1.2.4"
tar cf - --posix "statistics-1.2.4" | gzip -9n > "statistics-1.2.4.tar.gz"
Installing package locally ...
octave --silent --eval 'pkg ("install", "statistics-1.2.4.tar.gz")'
For information about changes from previous versions of the statistics package, run 'news statistics'.
And of course, there's nothing stopping you from calling make install from the Octave session itself. The statistics package example is nicer because it only has m files. If your package also has code to be compiled, the image package has a more complex, but not by much, Makefile for that.
I'm relatively new to Go and I've recently created a project that's going up on GitHub. I've tried to follow guides but there's a pressing question of why my binaries end up in src/?
My layout is like this:
ssm/ - Name of project
LICENSE
README.md
src/ - Source Code
files.go - All my source code is here.
src - The compiled binary ends up here
bin/ - Binaries
I set my $GOPATH to ~/Documents/Programming/Go/. From my gopath, I can't type go build ssm because it cannot find package. If I cd into the directory, it complains it can't load package: package .: no Go source files.
I have to actually go into src and compile there, which means the binary isn't in bin/.
What am I doing wrong?
See https://code.google.com/p/go-wiki/wiki/GithubCodeLayout
To be compatible with go get, your project's package name needs to be fully-qualified under the github.com domain:
$GOPATH/
src/github.com/<user>/ssm/
.git
LICENSE
README.md
files.go
bin/
Note that the base of the git repository (.git) is not the same as the $GOPATH.
Also, go build <package> will output a compiled executable to the current directory. If you want the exe to go to bin/, use go install <package> instead.
Your go code you can kept in a workspace. A workspace contains many source files (git, hg, svm, etc.). The Go tool understand the layout. We don't require Makefile or build.xml here. The basic directory layout is everything. If in any case if you are going to change the file layout, accordingly you need to change the build.
This is the general structure you can follow,
$GOPATH/
src/
github.com/username/repo/
mypkg/
mysrc1.go
mysrc2.go
cmd/mycmd/
main.go
bin/
mycmd
And, this is the standard workspace
$GOPATH/
bin/fixhub # installed binary
pkg/darwin_amd64/ # compiled archives
code.google.com/p/goauth2/oauth.a
github.com/...
src/ # source repositories
code.google.com/p/goauth2/
.hg
oauth # used by package go-github
...
github.com/
golang/lint/... # used by package fixhub
.git
google/go-github/... # used by package fixhub
.git
dsymonds/fixhub/
.git
client.go
cmd/fixhub/fixhub.go # package main
go get fetch many repositories whereas go install builds a binary out of them. It's convenient and easy to go for go development quickly. And, everyone in the go community follows the same. This puts src, bin and pkg into the home directory. And, $HOME/bin is already in our path before creating our workspace.