I am trying to put up my first php project on packagist.org but my vendor name is already taken. I have already pushed a tagged release to github; now I have to modify my composer file without creating a new git tag which isn't as simple as just pushing your changes to github. My question is: how do I do a namespace check before naming the package? Same issue with the code name spacing too. How can I do a lookup to prevent a clash?
You can do a check using search:
composer search somevendor
Then just wait to see if some packages pop up.
You can't really do a check for namespacing though. I guess your best bet is sticking with your vendor name. And even if you have a colliding vendor name, your project name will usually still differ.
Related
How to download the exact source code of a specific LineageOS Android build?
For example this one:
https://download.lineageos.org/FP3
sha256 039a65b5365acd4d570fab1c034f450f32f04ca6f5371602adc6a9736bffe015
lineage-19.1-20221031-nightly-FP3-signed.zip
Goal: being able to manually inspect the (Open Source) source code and verify that no arbitrary code has been manipulated in this specific build.
Preamble
When I download an app like Termux from F-Droid I can:
verify the PGP signature (verifying package authority and integrity)
inspect the build log (checking for controversial passages from unusual libraries)
download the original source tarball and inspect the source code (most important for me)
How to do the last verification step on a specific LineageOS build?
Notes
https://security.stackexchange.com/q/266348/ - this question migrated from the Information Security network
https://wiki.lineageos.org/verifying-builds - page describing how to verify digital signature (not how to download the sources of a specific version)
https://download.lineageos.org/FP3 - downloads for the Fairphone 3 where there is not the possibility to neither download the exact source code neither see the exact commit hash)
https://wiki.lineageos.org/devices/FP3/build - how to build your own version (now about how to inspect the source code of an exact already-existing build)
https://wiki.lineageos.org/signing_builds - how to sign my builds (same problem as above)
https://mirrorbits.lineageos.org/full/FP3/20221114/lineage-19.1-20221114-nightly-FP3-signed.zip this is the URL of a specific build, but its parent directory cannot be visited https://mirrorbits.lineageos.org/full/FP3/20221114/ so I can't tell if there are any other files (like the source code tarball of that exact version)
https://github.com/LineageOS/android_device_fairphone_FP3 AFAIK this is the repository of the Fairphone 3 (but I see no reference between the specific image in the download page, and its specific git tag or git hash etc.)
At the moment it seems to me that I have to take the date from the download page (e.g. 20221114) and manually guess the exact commit hash from the official repository. This seems to me an unscientific way to proceed.
Thank you for the clarification about how to download the exact source code of whatever specific official LineageOS build.
Short answer, you can't.
Long answer: you could, but in this way you won't ever get the same precise package. And (imho) you'll waste a ton of time and resources, too.
LineageOS has tons of repos, it's not just one repo. You could still sync the entire source from their manifest and checkout everything at a specific date, in your case at the test build's date.
After that, you could build an unofficial build by yourself, using the LineageOS building guide. Though, it won't match precisely the official build because, among other factors, you're missing the signing key used to sign the official builds, which is private (as it should be). This is what differentiates an official build from an unofficial one.
Regarding the checkout part, you can check here regarding the latest commits added in that specific build.
Good luck!
I'm using PhpStorm 10 to work on a craftCMS project, and I'd like to register *.html as a pattern for Twig files as discussed here.
My question: Is there a way to do this in a manner that it will only affect this particular project, allowing my other projects to still use that pattern to identify HTML files?
...that it will only affect this particular project...
Unfortunately no.
https://youtrack.jetbrains.com/issue/IDEABKL-6335 -- watch this and related tickets (star/vote/comment) to get notified on any progress.
Right now this ticket is located in "IDEA Backlog" project .. which means that it's quite unlikely that it will be implemented any time soon. Plus, developers clearly stated (comment 1 & comment 2) that they do not really plan to implement such stuff.
That being said, it is something that could be written into a plugin (an example).
To use twig in PHPStorm for CraftCMS one can simply rename those .html files to .twig and Craft will load them fine.
First, some context: I drive qooxdoo from other languages such as Lisp and ClojureScript, and I dynamically generate code to reference individual classes.
This normally fails because the qooxdoo generator looks through the static source to see which classes to include.
In the past I have just whomped explicit mentions of classes into Application.js. This works great, but recently I started to grok the config.json syntax and thought it would be nice to take a less kludgy approach.
I managed to add code like this to the "source-build" job and that build then worked:
"include" : ["qx.ui.mobile.page.Manager"]
But I use many classes in an app, so adding that to each job would be error-prone and still ugly.
I tried adding the "include" to the "mobile-common" job which the other jobs extend but to my surprise that did not work. Hmm.. could there be a bug in the job "extend" logic?
I could just add "include" : ["qx.ui.mobile.*"] to all the jobs but that is still ugly and excessive (and I would have still to pull in multiple other classes in each job).
Looking back at all this, it seems there would be no problem if the job "extends" mechanism successfully picked up the "include" option. I just ran the generator with the verbose option -v and can confirm the page manager class is not included if I add the "include" to mobile-common, but it is if I do so on the specific job.
Am I missing something?
Kenny,
you're quite right using the "mobile-common" job, and it is really strange that it doesn't work. As I don't know your exact config.json file I can only provide some guesses here:
The default "mobile-common" job provided with the mobile skeleton already contains an "include" key. You did not by any chance add a second one to the job?!
Are you using the mobile config.json directly, or did you create another config file and are including the one that contains the default "mobile-common"? If you use job shadowing (i.e. define "mobile-common" in one config file but also in another which is included by the first), this will influence the content of the resulting job definition (maybe in an unexpected way).
The default "mobile-common" job has (for whatever reason) a = in front of the include key, to protect from overriding. You might want to remove that and see what happens.
If all fails you can still create your own includer job (like "my-includes"), add an "include" key to it, and then add this job to the "extend" list of the relevant source* and build* jobs. Make sure to add it before the mobile-common entry. This way you can at least maintain your additional include patterns in a single place.
I'm working on a project with two other developers that's built on FireBreath. So far, I've been able to get things working perfectly on my machine, but we need to coordinate our development via Mercurial. So I pushed my files to the repository and thought all was well.
Unfortunately, that doesn't work.
The various .vcproj files that make up the solution all contain hard-coded references to my local file system. This works fine for me, because I'm not moving the project around. But when you try to build the solution on another machine with a different file structure (different drive letter, different folder location, etc.) everything breaks.
I used FireBreath's standard project generation script (Python) and then the Visual Studio CMake script (prep2008.cmd) to generate the solution files. What can I do to tweak things so that other developers can use the same code base?
If your developers are not using the same build/make/project files, this could quickly become a maintenance nightmare. So you should definitively all use the same .vcproj files. (An exception to this would be if the project files were generated from some other files. In that case treat those other files in the way described above.)
there's two ways to deal with the problem of differing setups on different machines. One is to make all paths relative to the project's path. The other is to use environment variables to refer to files/tools/libraries/whatever. IME it's best to use relative paths for everything that can be checked out with the project, and use environment variables for the rest. Add a script that checks for the existence of all necessary environment variable, pointing out the meaning of any missing ones, and run this as a build prerequisite, so whoever tries to get a new build machine up and running gets hints at what to do.
To make sure that everyone caught the updated comments from sbi's answer, let me give you the "definitive" answer from the FireBreath devs.
Your build directory is disposable; you should never share .vcproj files. Instead, you should regenerate your build/ directory any time you change the project and on each new computer, just like any project that uses CMake.
For more information, see http://colonelpanic.net/2010/11/firebreath-tips-working-with-source-control/
For reference, I am the primary author of FireBreath and I wrote the article.
I'm not familiar with FireBreath, but you need to make the references relative, and then recreate that relative structure on every machine. That is, if your project sits in "c:\myprojects\thisproject" and has an additional include directory "c:\mydir\mylib\include", then the latter path needs to be replaced with "....\mydir\mylib\include".
EDIT: I rewrote my anyswer to make it clearer. When I got you correctly, your problem is that FireBreath generates those .vcproj files with absolute paths in it, and you want to use this .vcproj files on a different developer machine.
I see 3 options:
Live with it. That means, make sure, every team member has the same file structure / view to the file system, tools installed in the same place.
Ask the authors of FireBreath to change their .vcproj generator to allow relative paths, use of environment variables etc.
If 1 or 2 does not work, write a program or script for changing the absolute path to relatives in those .vcproj files. Run this script whenever you have to regenerate your FireBreath project.
What you should not do due to the FireBreath FAQ: don't change the .vcproj manually, those changes will be lost next time the project is regenerated.
EDIT: seems that "option 4." turned out to be the best solution: generating those .vcproj files for each developer individually. Hope my suggestions were helpful, either.
I want to give credit to all open source libraries we use in our (commercial) application. I thought of showing a HTML page in our about dialog. Our build process uses ant and the third party libs are committed in svn.
What do you think is the best way of generating the HTML-Page?
Hard code the HTML-Page?
Switch dependency-management to apache-ivy and write some ant task to generate the html
Use maven-ant-tasks and write some ant task to generate the HTML
Use maven only to handle the dependencies and the HTML once, download them and commit them. The rest is done by the unchanged ant-scripts
Switch to maven2 (Hey boss, I want to switch to maven, in 1 month the build maybe work again...)
...
What elements should the about-dialog show?
Library name
Version
License
Author
Homepage
Changes made with link to source archive
...
Is there some best-practise-advice? Some good examples (applications having a nice about-dialog showing the dependencies)?
There are two different things you need to consider.
First, you may need to identify the licenses of the third-party code. This is often down with a THIRDPARTYLICENSE file. Sun Microsystems does this a lot. Look in the install directory for OpenOffice.org, for example. There are examples of .txt and .html versions of such files around.
Secondly, you may want to identify your dependencies in the About box in a brief way (and also refer to the file of license information). I would make sure the versions appear in the About box. One thing people want to quickly check for is an indication of whether the copy of your code they have needs to be replaced or updated because one of your library dependencies has a recently-disclosed bug or security vulnerability.
So I guess the other thing you want to include in the about box is a way for people to find your support site and any notices of importance to users of the particular version (whether or not you have a provision in your app for checking on-line for updates).
Ant task seems to be the best way. We do a similar thing in one of our projects. All the open source libraries are present in a specified folder. An Ant task reads the manifest of these libraries, versions and so on and generates an HTML, copies into another specified folder from where it is picked up by the web container.
Generating the page with each build would be wasteful if the libraries are not going to change often. Library versions may change, but the actual libraries don't. Easier to just create a HTML page would be the easiest way out, but that's one more maintenance head ache. Generate it once and include it with the package. The script can always be run again in case some changes are being made to the libraries (updating versions, adding new libraries).