I am little bit confusing with public/asset directory and public/package directory, which directory is prefered to add jquery third party plugin
public/asset contains your own application's assets, while public/package contains 3rd party and \ or packages' assets.
Sources:
https://laravel.com/docs/master/structure
https://laravel.com/docs/4.2/packages
Related
i was having issues on how vendor take too much place. Since my host has a limit on number of files and folders (INODES). So i found a solution to use one Vendor for multiple project in laravel through the following link : Using one Vendor Folder for Multiple Projects in Laravel 5.2.
In the following lines I put the vendor in projectA, then link the others projects to it.
In projectA everything works well when i do php artisan migrate:fresh --seed
When i try the same thing to projectB for example, the above command works till it arrives where the seeders should be executed. There, some error occur due to the fact that the command is trying to launch a seeder of projectA in the projectB as shown in the following screenshot.
Seeder Error Screenshot
So i want to know if there's a way to make the seeder separately.
I tried to create a symlink on the composer.json file as it was done for the vendor folder, but it doesn't work.
I'm using Laravel 8
I thínk this is a terrible idea, except in the case that both projects share exact same codebase.
Composer use composer.json as you know. How does your B project composer file determines how to resolve PSR4 autoload entries in Laravel, If it is symlinked to A project? That is probably the reason why your seed command is trying to locate Classes in A project.
Composer is clever enough to cache downloaded packages and reuse them, but I think that every project has its own dependencies and state, which is maintained by composer.json in the first case and composer.lock on the state case.
What happen if you update composer in A but not in B, will B work?
And last, composer autoload file reference all satisfied dependencies in your project, and in this case that (unique) autoload file will be loaded in both projects but what happen if your required packages are not exactly the same? ie You have Laravel Debug Bar in one project but not in the other. The autoload generated file will reference that package that will not exist on your other project.
Is not this the way composer work? Am I wrong?
In Composer the Vendor Directory (vendor in the project tree by default) is per project.
You ask about how to use one vendor folder for different projects.
Now first of all, this is absolutely not what Composer expects nor how it works. See Manuel Glez answer. In short a terrible idea.
When it comes to Composer, the place to share the actual PHP code across projects is not in the vendor directory but in repositories.
And as long as the dependencies are compatible, you could make one project depend on another and use its vendor/<vendor>/<name> folders as repositories. The remarks in Manuel Glez answer are still the same, this need to be same compatible versions across the board.
But to give the example, see Composer Path Repository which has this layout:
...
├── apps
│ └── my-app
│ └── composer.json
├── packages
│ └── my-package
│ └── composer.json
...
{
"repositories": [
{
"type": "path",
"url": "../../packages/my-package"
}
]
}
It can be adopted for each ../../project/A/vendor/<pkg-vendor>/<pkg-name> in ../../project/B/composer.json so that the vendor folder in project/A can act as a path repository for project/B.
As dependencies composer.json files normally do not contain the version, the documented remarks about repositories.options.versions apply:
When the version cannot be inferred from the local VCS repository, or when you want to override the version, you can use the versions option when declaring the repository:
{
"repositories": [
{
"type": "path",
"url": "../../packages/my-package",
"options": {
"versions": {
"my/package": "4.2-dev"
}
}
}
]
}
To prevent the duplication of the files the default strategy for Composer is to symlink the package directories. Ensure it works, then you only have one symbolic link per dependency in project B.
Okay how cool is that? Well IMHO while you still give up much of what Composer can do for you for dependency management, this at least makes use of local Composer repositories which I'd recommend for sharing instead of completely symlinking the overall vendor folder. Each project still have its own vendor/composer setup and overall what is done is much more well defined and in line with Composer itself.
Whether this works or not depends on the individual case. Key point here is as these local repositories only provide a single version per each package, you can only have that one. So these versions must all be version compatible on API level.
The system where it runs needs to support (relative) symbolic links, this should be commonly available for the situation described.
You could then automate the production of the repositories configuration and adopt it to the file-system layout. You could even generate the repositories and update them in the global configuration file so that each project would automatically prefer those packages from local.
$ echo "$(composer config --global home)/config.json"
/home/user/.config/composer/config.json
(compare: COMPOSER_HOME/config.json (Composer docs))
Take care all projects and their dependencies have a portable path-profile and then I'd say this should be quite straight forward shell processing.
To obtain the actual versions of the dependencies installed check per each vendor folder inside vendor/composer/*installed* files.
$ (echo "PACKAGE VERSION"; find .. -type f -path '*/vendor/composer/installed.json' -exec jq -r '.packages[] | .name + " " + .version_normalized ' {} \; | sort -u | sort -k 1b,2V) | cols
PACKAGE VERSION
composer/ca-bundle 1.3.2.0
composer/composer 2.3.7.0
composer/metadata-minifier 1.0.0.0
composer/pcre 3.0.0.0
composer/semver 3.3.2.0
composer/spdx-licenses 1.5.7.0
composer/xdebug-handler 3.0.3.0
...
phar-io/manifest 1.0.1.0
phar-io/manifest 1.0.3.0
phar-io/manifest 2.0.1.0
phar-io/manifest 2.0.3.0
...
(very old installations don't have the packages keyword, you'll likely want to filter)
Finally you may want to have something to smoke-test the setup easily so that you can have guards against the dependency incompatibility problems when you take notice of them.
Suppose you're developing some library, myproj, using CMake for build configuration; supporting the cmake --install (using install() commands); and supporting use of myproj with CMake config mode, i.e. by making relevant .cmake files accessible to dependent projects.
Now, ,given an install root directory - where should I install my project's configuration .cmake files? Is there an idiomatic standard(ish) location?
Sorush Khajepor's R&D blog suggests ${LIB_INSTALL_DIR}/cmake/myproj - and it's the newest.
Foonathan's blog suggests placing the config .cmake files in ${LIB_INSTALL_DIR}/. So does Falkor's blog.
The documentation page for the CMakePackageConfigHelpers module suggests: ${LIB_INSTALL_DIR}/myproj/cmake.
What's the most popular/idiomatic choice? And what are its pros and cons relative to the other ones?
I advocate for setting a cache variable to override this and defaulting it to <LIBDIR>/cmake/ProjName (as you suggest in your answer):
cmake_minimum_required(VERSION 3.21) # for saner CACHE variables
project(ProjName VERSION 0.1.0)
# ...
include(GNUInstallDirs)
include(CMakePackageConfigHelpers)
set(ProjName_INSTALL_CMAKEDIR "${CMAKE_INSTALL_LIBDIR}/cmake/ProjName"
CACHE STRING "Path to ProjName CMake files")
install(EXPORT ProjName_Targets
DESTINATION "${ProjName_INSTALL_CMAKEDIR}"
NAMESPACE ProjName::
FILE ProjNameConfig.cmake
COMPONENT ProjName_Development)
write_basic_package_version_file(
ProjNameConfigVersion.cmake
COMPATIBILITY SameMajorVersion)
install(FILES
"${CMAKE_CURRENT_BINARY_DIR}/ProjNameConfigVersion.cmake"
DESTINATION "${ProjName_INSTALL_CMAKEDIR}"
COMPONENT ProjName_Development)
I wrote a blog post with an expanded version of this a while back: https://alexreinking.com/blog/building-a-dual-shared-and-static-library-with-cmake.html
In general, setting an install() destination to anything other than "${SOME_CACHE_VARIABLE}" is bound to cause headaches for some package maintainer. Where GNUInstallDirs doesn't provide a valid configuration point, you must create your own.
I'll argue in favor of ${LIB_INSTALL_DIR}/cmake/myproj.
If you're installing to some library-specific install location, e.g. /opt/myproj - then it doesn't really matter all that much anyway. But think about what happens when you install to, say, /usr/local.
If you place the scripts in ${LIB_INSTALL_DIR}, that library now becomes full of foo-config.cmake and foo-version-config.cmake, instead of just library files (and some subdirs). Less fun for browsing and searching.
If you place the scripts in ${LIB_INSTALL_DIR}/myproj/cmake, then - the same thing happens, but with per-project subdirs instead of sets of files. Better, perhaps, but instead - why don't we just replace the path elements of myproj and cmake, and that way we would get a cmake/ directory with many subdirs, instead. That's cleaner and more convenient IMHO.
Facebook's Pysa tool looks useful, in the Pysa tutorial exercises they refer to files that are provided in the pyre-check repository using a relative path to include a path outside of the exercise directory.
https://github.com/facebook/pyre-check/blob/master/pysa_tutorial/exercise1/.pyre_configuration
{
"source_directories": ["."],
"taint_models_path": ["."],
"search_path": [
"../../stubs/"
],
"exclude": [
".*/integration_test/.*"
]
}
There are stubs provided for Django in the pyre-check repository which if I know the path where pyre check is installed I can hard-code in my .pyre_configuration and get something working but another developer may install pyre-check differently.
Is there a better way to refer to these provided stubs or should I copy them to the repository I'm working on?
Many projects have a standard development environment, allowing for hard coded paths in the .pyre_configuration file. These will usually point into the venv, or some other standard install location for dependencies.
For projects without a standard development environment, you could trying incorporating pyre init into your setup scripts. pyre init will setup a fresh .pyre_configuration file with paths that correspond to the current install of pyre. For additional configuration you want to add on top of the generated .pyre_configuration file (such as a pointer to local taint models), you can hand write a .pyre_configuration.local, which will act as an overlay and overwrite/add to the content of .pyre_configuration.
Pyre-check looks for the stubs in the directory specified by the typeshed directive in the configuration file.
The easiest way is to move stubs provided for Django in the pyre-check repository to the typeshed directory that is in the pyre-check directory.
For example, if you have installed pyre-check to the ~/.local/lib directory, move the django directory from ~/.local/lib/pyre_check/stubs to ~/.local/lib/pyre_check/typeshed/third_party/2and3/ and make sure your .pyre_configuration file will look like this:
{
"source_directories": ["~/myproject"],
"taint_models_path": "~/myproject/taint",
"typeshed": "~/.local/lib/pyre_check/typeshed"
}
In this case, your Django stubs directory will be ~/.local/lib/pyre_check/typeshed/third_parth/2and3/django
Pyre-check uses the following algorithm to traverse across the typeshed directory:
If it contains the third_party subdirectory, it uses a legacy method: enters just the two subdirectories: stdlib and third_party and there looks for any subdirectory except those with names starting with 2 but not 2and3, and looks for the modules in those subdirectories like 2and3, e.g. in third_party/2and3/
Otherwise, it enters the subdirectories stubs and stdlib, and looks for modules there, e.g. in stubs/, but not in stubs/2and3/.
That's why specifying multiple paths may be perplexing and confusing, and the easiest way is to setup the typeshed directory to ~/.local/lib/pyre_check/typeshed/ and move django to third_parth/2and3, so it will be ~/.local/lib/pyre_check/typeshed/third_parth/2and3/django.
Also don't forget to copy the .pysa files that you need to the taint_models_path directory. Don't set it up to the directory of the Pyre-check, create your own new directory and copy only those files that are relevant to you.
I am new to composer and I used it to install the oauth2-client. I think I am having some sort of misunderstanding about how this is supposed to work.
From thephpleague github page I installed from the command line using
composer require league/oauth2-client
This added files to /usr/local/bin/vendor/league/oauth2-client.
The file structure looks the same as it does on github, except I don't have all the same files.
And the php in the files is looking for files in \League\OAuth2, so I am getting errors that it can't find included files, because I don't have that directory.
Did I do it wrong, or am I just not getting something?
The backslash is the PHP namespace separator, not the directory separator.
In the composer.json for oauth2 from TheLeague, this is the autoload directive:
"autoload": {
"psr-4": {
"League\\OAuth2\\Client\\": "src/"
}
},
It says that the code inside of src directory is in the League\OAuth2\Client namespace.
Composer follows PSR-4 with regards to namespacing and autoloading, so check that out if you want to know what goes on.
UPDATE:
If you've installed other League extensions, like oauth2-facebook, it will install itself into the same src directory - because of the autoload directive in composer.json.
Why?
Well, because of the namespace, you will find 'Facebook' in the League\OAuth2\Client\Provider namespace.
Because of PSR-4, this means that they need to go into the same directory, even though they are different packages.
That is the reason why you'll see Facebook.php in src/Providers directory. Check the oauth2-facebook repository
You probably have required oauth2-facebook and oauth2-google, or one of your other required packages requires it. It rarely just add themselves. :)
I'm starting to learn ruby. I'm also a day-to-day C++ dev.
For C++ projects I usually go with following dir structure
/
-/bin <- built binaries
-/build <- build time temporary object (eg. .obj, cmake intermediates)
-/doc <- manuals and/or Doxygen docs
-/src
--/module-1
--/module-2
-- non module specific sources, like main.cpp
- IDE project files (.sln), etc.
What dir layout for Ruby (non-Rails, non-Merb) would you suggest to keep it clean, simple and maintainable?
As of 2011, it is common to use jeweler instead of newgem as the latter is effectively abandoned.
Bundler includes the necessary infrastructure to generate a gem:
$ bundle gem --coc --mit --test=minitest --exe spider
Creating gem 'spider'...
MIT License enabled in config
Code of conduct enabled in config
create spider/Gemfile
create spider/lib/spider.rb
create spider/lib/spider/version.rb
create spider/spider.gemspec
create spider/Rakefile
create spider/README.md
create spider/bin/console
create spider/bin/setup
create spider/.gitignore
create spider/.travis.yml
create spider/test/test_helper.rb
create spider/test/spider_test.rb
create spider/LICENSE.txt
create spider/CODE_OF_CONDUCT.md
create spider/exe/spider
Initializing git repo in /Users/francois/Projects/spider
Gem 'spider' was successfully created. For more information on making a RubyGem visit https://bundler.io/guides/creating_gem.html
Then, in lib/, you create modules as needed:
lib/
spider/
base.rb
crawler/
base.rb
spider.rb
require "spider/base"
require "crawler/base"
Read the manual page for bundle gem for details on the --coc, --exe and --mit options.
The core structure of a standard Ruby project is basically:
lib/
foo.rb
foo/
share/
foo/
test/
helper.rb
test_foo.rb
HISTORY.md (or CHANGELOG.md)
LICENSE.txt
README.md
foo.gemspec
The share/ is rare and is sometimes called data/ instead. It is for general purpose non-ruby files. Most projects don't need it, but even when they do many times everything is just kept in lib/, though that is probably not best practice.
The test/ directory might be called spec/ if BDD is being used instead of TDD, though you might also see features/ if Cucumber is used, or demo/ if QED is used.
These days foo.gemspec can just be .gemspec --especially if it is not manually maintained.
If your project has command line executables, then add:
bin/
foo
man/
foo.1
foo.1.md or foo.1.ronn
In addition, most Ruby project's have:
Gemfile
Rakefile
The Gemfile is for using Bundler, and the Rakefile is for Rake build tool. But there are other options if you would like to use different tools.
A few other not-so-uncommon files:
VERSION
MANIFEST
The VERSION file just contains the current version number. And the MANIFEST (or Manifest.txt) contains a list of files to be included in the project's package file(s) (e.g. gem package).
What else you might see, but usage is sporadic:
config/
doc/ (or docs/)
script/
log/
pkg/
task/ (or tasks/)
vendor/
web/ (or site/)
Where config/ contains various configuration files; doc/ contains either generated documentation, e.g. RDoc, or sometimes manually maintained documentation; script/ contains shell scripts for use by the project; log/ contains generated project logs, e.g. test coverage reports; pkg/ holds generated package files, e.g. foo-1.0.0.gem; task/ could hold various task files such as foo.rake or foo.watchr; vendor/ contains copies of the other projects, e.g. git submodules; and finally web/ contains the project's website files.
Then some tool specific files that are also relatively common:
.document
.gitignore
.yardopts
.travis.yml
They are fairly self-explanatory.
Finally, I will add that I personally add a .index file and a var/ directory to build that file (search for "Rubyworks Indexer" for more about that) and often have a work directory, something like:
work/
NOTES.md
consider/
reference/
sandbox/
Just sort of a scrapyard for development purposes.
#Dentharg: your "include one to include all sub-parts" is a common pattern. Like anything, it has its advantages (easy to get the things you want) and its disadvantages (the many includes can pollute namespaces and you have no control over them). Your pattern looks like this:
- src/
some_ruby_file.rb:
require 'spider'
Spider.do_something
+ doc/
- lib/
- spider/
spider.rb:
$: << File.expand_path(File.dirname(__FILE__))
module Spider
# anything that needs to be done before including submodules
end
require 'spider/some_helper'
require 'spider/some/other_helper'
...
I might recommend this to allow a little more control:
- src/
some_ruby_file.rb:
require 'spider'
Spider.include_all
Spider.do_something
+ doc/
- lib
- spider/
spider.rb:
$: << File.expand_path(File.dirname(__FILE__))
module Spider
def self.include_all
require 'spider/some_helper'
require 'spider/some/other_helper'
...
end
end
Why not use just the same layout? Normally you won't need build because there's no compilation step, but the rest seems OK to me.
I'm not sure what you mean by a module but if it's just a single class a separate folder wouldn't be necessary and if there's more than one file you normally write a module-1.rb file (at the name level as the module-1 folder) that does nothing more than require everything in module-1/.
Oh, and I would suggest using Rake for the management tasks (instead of make).
I would stick to something similar to what you are familiar with: there's no point being a stranger in your own project directory. :-)
Typical things I always have are lib|src, bin, test.
(I dislike these monster generators: the first thing I want to do with a new project is get some code down, not write a README, docs, etc.!)
So I went with newgem.
I removed all unnecessary RubyForge/gem stuff (hoe, setup, etc.), created git repo, imported project into NetBeans. All took 20 minutes and everything's on green.
That even gave me a basic rake task for spec files.
Thank you all.