what meteors meteoroids meteoroid asteroid meteor meteorite

meteoroids - meteors



¿Cómo bifurcar un paquete Meteorite existente de forma limpia? (4)

Estoy tratando de encontrar la manera mejor / más limpia de incluir un paquete existente en Atmosphere dentro de un proyecto. Me encontré con algunas ocasiones en las que un paquete existente necesitaba algunas modificaciones y me vi obligado a hacerlo.

Por lo que sé, existen las siguientes opciones. Desafortunadamente, todos estos tienen sus propios problemas y todavía tengo que encontrar la solución perfecta. meteor-router como ejemplo:

1. Simplemente copie los archivos del paquete en su carpeta de paquetes

Pasos:

  • eliminar packages/router/.git/
  • edita los packages/.gitignore y elimina la línea ''enrutador''
  • quitar el enrutador de su smart.json
  • Agregue packages/router a su repositorio de proyectos y confirme
  • ahora haga cambios (de esta manera, su confirmación inicial es una versión limpia y usted puede resolver lo que ha cambiado usted mismo)

Ventajas:

  • fácil de lograr y entender
  • Todo el código en el que confía se puede encontrar en el repositorio de su proyecto

Desventajas:

  • Pierdes toda la historia de los repositorios originales.
  • es difícil actualizar a una versión más nueva
  • Es difícil aportar tus cambios al proyecto original.

¡Ni siquiera consideres esto para ninguno de los paquetes más simples!

2. Tenedor en github, entonces ...

Para bifurcar un paquete en github, puede revisar su archivo smart.lock para ver qué repositorio se está utilizando. Vaya a la página github de ese repositorio y bifurque.

A continuación, tienes tres opciones:

2a. Añadirlo como un submódulo de git.

Más información sobre los submódulos de git: http://git-scm.com/book/en/Git-Tools-Submodules

Pasos:

  • Vea el enlace anterior sobre cómo iniciar / crear / actualizar un submódulo
  • Retire el paquete de su smart.json

Ventajas:

  • Las versiones de submódulos están conectadas a su proyecto.
  • Los cambios son recogidos inmediatamente.

Desventajas:

  • Todos los desarrolladores necesitan ejecutar git submodule init la primera vez y update para actualizar
  • Debe tener en cuenta los problemas con los submódulos al editar el proceso de pago.
  • Lea sobre otros temas con submódulos

2b. Edite el smart.json su proyecto para usar su versión.

Pasos:

  • En su smart.json , encuentre "router": {} y agregue "git": "https://github.com/USER/meteor-router.git" dentro del vacío {} .
  • Opcionalmente, agregue una "branch" o "tag" .

Ventajas:

  • Aún puedes usar Meteorite para administrar tus paquetes externos
  • Trabajará automáticamente para otros desarrolladores y en entornos de implementación.

Desventajas:

  • El código en su carpeta de paquetes no es editable, ya que no es un repositorio git
  • Meteorite no se actualizará automáticamente a la última versión cada vez que lo ejecute

(Mejora sugerida de Meteorite: permite que los paquetes se instalen en una forma editable, como el pip de Python permite usar el parámetro ''-e'')

2c. Clone fuera de su proyecto y agregue una "path" a smart.json

Pasos:

  • Clona el paquete a un lugar fuera de tu proyecto
  • De manera similar a 2b, agregue una "path" a su smart.json para apuntar Meteorite a su pago local

Ventajas:

  • Puede editar el paquete a voluntad y Meteor recogerá automáticamente los cambios.

Desventajas:

  • Si confirma este smart.json , lo más probable es que rompa todos los demás entornos de desarrollo / implementación ...

¿Qué método utilizas? ¿Cómo se resuelven las desventajas de ese método?

Podría haber perdido algunos problemas con estas soluciones.

2b. Edite el smart.json de su proyecto para usar su versión.

Recomendaría esta versión, ya que es la más coherente con la smart.json se diseñó y smart.json el smart.json . mrt update reflejará correctamente lo último del git repo , creo.

Hay una respuesta aún más fácil que todas las anteriores. Cree un directorio llamado paquetes en su proyecto y coloque el paquete que desea anular en él. ¡Sencillo!

Ej .: Digamos que desea hacer algunos cambios en accounts-ui-unstyled (que es una accounts-ui-unstyled de accounts-ui ) de meteoro. Haga un clon de git de toda la fuente de meteoros a un repositorio local:

MyMachine:~ theuser$ cd Development/ MyMachine:Development theuser$ git clone https://github.com/meteor/meteor.git MyMachine:Development theuser$ cp accounts-ui-unstyled ~/Development/MyProject/packages

En tu estructura de proyecto tendrías esto

MyProject | -> client -> lib -> packages | -> accounts-ui-unstyled -> private -> public -> server -> tests

Cualquier cambio que realice dentro de MyProject / packages / accounts-ui-unstyled ahora anulará el paquete.

Para Meteor 1.0 recomiendo lo siguiente:

  1. Configurar una carpeta de paquetes locales

    $ mkdir "$HOME/code/packages"

  2. Agregue la variable de entorno PACKAGE_DIRS a su archivo .bashrc / .zshrc

    export PACKAGE_DIRS="$HOME/code/packages"

  3. Tenedor y clonar el repositorio.

    $ cd "$HOME/code/packages" $ git clone <yourGithubFork>

  4. Instala el paquete desde tu sistema de archivos.

    $ meteor add <packagenamespace>:<packagename>

Utilizo un híbrido de las opciones # 2: smart.json en un checkout local, pero coloco todos los paquetes, incluidos la aplicación y los paquetes smart extraídos, como submódulos de git en un proyecto principal. Meteorite todavía instala el resto de los paquetes inteligentes en la aplicación. De esta manera, cuando desarrollas los paquetes inteligentes, todo se mantiene constante y puedes mover tu aplicación a Meteorite normal cuando tu fork se fusiona.

Consulte https://github.com/mizzao/CrisisMapping para ver un ejemplo. En mi caso, esos ni siquiera son bifurcaciones, son solo paquetes inteligentes que estoy desarrollando más allá de la última versión de Meteorite.