I have a local repository set up in my global config, which I develop composer packages in. This way I can easily test them out in multiple locations by simply running composer require my/package. When I release these packages, I'd like to be able to keep the local copy, but select from which repository I can require these. Is this possible? Something like:
composer require --repository local my/package
composer require --repository my-satis-instance my/package
Why not deal with the versions?
Usually I would use a stable version like 1.0.3 in production but dev-master in development mode. This way you can switch easily between actual development and stable.
Therefore it doesn't matter if you use the local or the public repo. Because stable versions should be the same in public and local repos. Once published as a version this version never changes again (changes would increase version number).
So e.g. if you switch on local repo from dev-master to 1.0.3 it should be the same as if you switched to public repo 1.0.3. So you can keep your local repo in your dev environment.
Related
We have a React App which uses some components written by us and published to our internal npm repository. Our code is maintained in Bitbucket Data Center, the build is done with Bamboo and the npm repository is hosted in JFrog Artifactory. We work with feature branches and pull requests for developing new features.
It happens often that a new feature in the app, requires a change in the component. In this case, each repository (the App and the component) will have its own feature branch and pull request. Many times the component interface changes, so that the App needs the pull request version of the component and not the mainline one to build and to be tested.
The build is done exclusively by the build server, so that the bundled javascript files are not committed to git.
Let's say the component has version 1.0.0. A new feature in the App needs a change in the component. In this case, the component version will incremented to 1.0.1. We don't want to publish it to Artifactory, until version 1.0.1 is tested, but at the same time, the build of the new App version needs the changes from version 1.0.1.
Our current solution is to change the package version of the component during the build of feature branches to something like 0.<Ticket #>.<Build #>. This 0.x.x version will be published to Artifactory so that the App feature branch can use it to compile.
We use 0.x.x so that the version is never bigger than the current released version. Once the component is merged to the main branch, it will compile with the right version (1.0.1) and will be published to Artifactory again.
I find this solution cumbersome, it requires some funny build scripts, making sure that the branch name always follows some convention and teaching developers about it.
I wonder if there is a better way for managing pull requests and feature branches using npm, without having to manipulate the package.json during build time, depending if it is a feature branch or the main branch.
Sounds like you are using artifactory like a secondary version / staging for the npm package, just use npm?
I am not in devops, but have worked on a few packages, testing a package that has not been released does not sound like testing the package - what about using a beta tag npm publish --tag beta, pulling that into your app npm i package#beta then testing your application in a staging environment?
As i expect you know if you apply a tag then the tag would need to be specified to be pulled into a repo so you can use it to deter users from using that version of the package - an i believe you can delete versions later if you are dead set on not having it public.
Here is a medium article which may be helpful?
I am designing an environment for productive research, i.e. writing, data-analysis, publication, etc.
In order to share the final results with others, I need to find a way to package this and to set up the local installation.
The project depends on Anaconda, so conda as a package manager is available.
It also includes
Pandoc and some pandoc packages, some will have to be fetched from Github directly because some versions are not available via conda-forge (doable in conda)
Atom and Atom packages; they should be installed and configured by my script (this works on the CLI via the apm package manager)
Node.js and Mermaid and a few other JS packages, which require npm calls
Some file-system-level operations, like deleting parts from packages where I only need a portion from, creating symlinks and aliases etc.
Maybe some Python code for modifying yaml/json/ini files or reading therefrom.
The main project will reside in a Github repository. It will be fine for users to clone it from there and start a build script locally.
My idea is to write a Bash shell script that
creates a conda environment based on requirements.yaml for everything that can be done this way
installs other parts using CLI commands (wget/curl etc.)
does all necessary modifications using CLI commands, maybe using a few short Python scripts (e.g. for changing or reading JSON or yaml files).
My local usage will be on OSX Big Sur, Linux should be supported, Windows compatibility would be nice-to-have.
Before I start:
Is this approach viable? I think it will be pretty transparent, but of course also a bit proprietary.
Docker is likely overkill for my purpose, and I also read that the execution will be slow on OSX.
The same environment will likely be installed multiple times on the same users' machine, so it is important that I can control e.g. the usage of existing packages and files via aliases or symlinks. It is not important that the multiple installations are decoupled for the non-python/non-conda parts (e.g. atom, node.js, mermaid could be the same binaries for all installations; just the set of Python packages might vary by installation).
Thanks for your expertise!
I have couple of NPM packages that requires binary files during it's installing process. (For example, during node-sass installation scripts, the package requires a binary file that could be found on node-sass releases page).
My team is working on private network environment (disconnected from github) and therefore we need to host/serve the binaries privately.
At the moment, we use the sass_binary_dir parameter which makes the install script to look for the files in a shared drive that contains the needed binaries.
That method is fine for node-sass but is not working for other packages that requires the real binary repository or another website / proxy but not filesystem location or directory.
I would like to know if there is a recommended way to host the files ? (Something like Verdaccio but for binary files).
I also thought about fileZilla but it seems as a bit uncomfortable solution.
Writing a server myself could be fine as a temporary solution, but in the future I belive it would have to be maintained by another more organized solution.
The solution there was to create a simple API that enables fetching the package over HTTPS / FTP.
For a project I'm working on, I'd love to be able to make use of the maven_artifact module in the Ansible Extras repository.
However, the project uses Ansible stable (currently 1.9.3) and the module is documented as only being available from version 2.0 onwards (which looks to still be in alpha).
What's the best way to "backport" this module to our current Ansible install, across many machines?
Will dropping the "maven_artifact.py" file into the "ansible/modules/extras/packaging/language/" directory on each machine work? Or will the line in the source code:
version_added: "2.0"
prevent it from running due to some sort of compatibility check?
Additionally, how can I tell whether the module relies on features present in Ansible version 2.0 and therefore is incompatible and won't run on 1.9.3 or whether it's just that version 2.0 is when it's set to be introduced?
2.0 had very minimal changes to the module subsystem- most 2.0 modules will work fine in 1.9.x (there's no version check). The easiest way to use it is to copy the source for the module you want to use from the Github extras repo to a directory called library next to your playbooks. If you have your Ansible content checked into a source-control repo of some kind, put the library directory in there too- then all your Ansible machines where you've checked out your playbook content can run the module without you needing to copy it around manually.
Ok, perhaps I'm trying to accomplish something not doable.
I am a single developer (not part of team).
I'm trying to get some kind of versioning system going. I had used CVS with XCode 3, but XCode 4 no longer has that as an option. I've heard that SVN and Git are better alternatives anyway.
Basically, I've wasted more than half a day trying to get XCode to work with SVN / Git out of the box. I do not have a server running, and would rather not expose my project on a server.
It doesn't make sense for me to have a separate user just to run the Git/SVN Servers, either.
I'm just trying to have version control using either one, in the simplest possible way.
I've tried to add Repo, using local file path (/Volumes/AAA/BBB/Repo) where I manually created the "Repo" directory. I've set the type as Subversion (and also tried Git). XCode says "Host is reachable". But, the Commit functionality is not there (Disabled). I can't import my working directory.
I just don't get it - must I have a server running in order to have SVN/Git, or can XCode just do it through command line? I much more prefer it being done over command line, since the server is complete overkill. Or, am I missing something? Maybe I'm putting in the wrong settings into XCode?
This isn't strictly an XCode 4 issue, I had the same issue with XCode3, but at least it had the CVS option - now it's gone.
With Git you don't need a central server or even a central repository unless you have multiple people on the project. SVN requires you to have a central repo & server running all the time, but with Git you can simply git init a new repo and start using it. If you don't have a central repo you will never use push, pull, or fetch.
Xcode's help mentions the following:
Choose Git or Subversion Xcode supports two SCM systems: Subversion
(often abbreviated svn) and Git. Subversion is always server-based and
the server is normally on a remote machine, though it is possible to
install one locally. Git can be used purely as a local repository, or
you can install a Git server on a remote machine to share files among
team members. The Xcode 4 installer installs the Git and Subversion
tools when you select System Tools. If you are working alone, it’s
generally easiest to use Git, as you don’t need to set up a server. In
fact, Xcode can automatically set up a Git repository for you when you
create a new project (see “Create a Git Repository For Your New
Project”). For a group project, the choice of Subversion or Git is
usually a matter of taste and prior experience. In so far as is
possible, Xcode provides a consistent user interface and workflow for
users of either Subversion or Git.
So the official advise is that in your case, Git is the easiest solution. I'm now in the same position as you described and will be trying Git as advised.
Previously, when working for a small company, we used a dedicated leftover MacMini as an SVN server; this was quite easy to set up, and worked like a charm for many years. Be aware that the SVN integration of Xcode 3 was better than that of Xcode 4 though, so that I ended up using Xcode 4 for development and basic SVN usage, together with Xcode 3 for SVN stuff that Xcode 4 wouldn't do anymore.