Automatizacion: Diario de Lecherito

Lecherito

Pues dia hiperproductivo hoy, al final me he puesto tambien con el cli de los workspaces y lo he dejado casi listo para una primera version. Me falta algo mas de testeo pero me vale por ahora conforme se ha quedado.

Le he a;adido unos cuantos subcomandos al binario. create/clone/add/remove/clean. Y es bastante directo todo:

fn main() {
    let args = Cli::parse();
    match &args.command {
        Commands::Create{ name } => {
            create_workspace(name);
        },
        Commands::Clone => {
            clone_workspace();
        },
        Commands::Add { name } => {
            add_package(name);
        },
        Commands::Remove { name } => {
            remove_package(name);
        },
        Commands::Clean => {
            clean_workspace();
        }
    };
}
struct Cli {
    #[clap(subcommand)]
    command: Commands,
}

#[derive(Parser)]
enum Commands {
    Create{ name: String },
    Clone,
    Add { name: String },
    Remove { name: String },
    Clean,
}

Y un ejemplo de la funcion y comando

fn add_package(name: &String) {
    let mut workspace = parse_workspace();

    // add package (repo) and then refresh the content of the Projects file
    workspace.projects.push(name.to_string());
    let serialized_projects = serde_json::to_string_pretty(&workspace).unwrap();

    let mut file = File::options().write(true).read(true).open("Projects").expect("Could not create the Projects file");
    file.set_len(0).unwrap();
    file.write_all(serialized_projects.as_bytes()).expect("Error writing the Projects file");
}

Asi que mas o menos ya tengo una manera de hacer workspaces. Tengo todavia algunas ideas alrededor de todo esto pero por ahora creo que tengo esto funcionando de una manera con la que estoy relativamente satisfecho. Lo siguiente es actualizar el los templates que tengo (tambien tengo unas cuantas ideas alrededor de esto) y ponerme con el builder.

1 respuesta
JuAn4k4

#91 Te das cuenta que te estás haciendo mucho tooling para programar ? Igual te va bien hacerlo open source y buscar gente que quiera colaborar, si es que tiene salida vaya, no se muy bien para que es todo el tooling que tienes montado (me parece que va de dependencias y proyectos/plugins o algo así) pero no me he enterado bien.

1 respuesta
Lecherito

#92 sep, pero es que en el fondo me divierte mucho mas que la logica actual de negocio. Antes perdia todo el tiempo en hacer (y reinventar) los defaults que estoy haciendo con todo esto y ahora ya lo tendre todo hecho y de una manera que es la misma para todos los proyectos.

Sobre open source es algo que he hecho muchas veces y que solo una vez he llegado a recibir issues/prs pero al final lo acabe dejando porque o bien me interese por otras cosas, o bien yo ya no lo neceistaba y al final al ver las issues etc sientes como una obligacion. Sinceramente no me gustaria volver a pasar por ello de nuevo, si algun dia esto lo saco open source (nunca lo he descartado), sera porque ya lo tengo en un estado que me gusta y que es valido, por ahora solo estoy probando mis mierdas a ver cual puede ser el workflow con el que mejor trabajo.

Lo siguiente creo que incluso se merece su hilo propio xDD, pero bueno, aqui va.

Respecto a lo que estoy haciendo ahora mismo, por el momento estoy haciendo una manera mas facil de trabajar con una agrupacion de proyectos que estan relacionados entre si. No se si has trabajado con maven/gradle (creo que node es igual), donde basicamente pones las dependencias y estas seran resueltas en tiempo de compilacion al hacer mvn compile, gradle build o el equivalente en js. La cosa es que si trabajas con una version 1.0 del proyecto A del que dependen B y C, ahora mismo con gradle (en maven supongo que sera lo mismo, es la misma cache), no puedes trabajar con el proyecto A y B a la vez sin que C se vea afectado por las modificaciones locales en A. Ahora bien, si cambias la version del proyecto A a 1.1 y la cambias en B a la misma version, C seguira en la 1.0 y no habra ningun problema. La cosa cambia cuando esto lo tienes que hacer muy a menudo y has de subir versiones demasiadas veces. Al final pense (tambien lo he visto en el lugar de trabajo), que es mucho mejor depender de una version en concreto y que 1, la dependencia se pueda modificar solo en local, 2 no haga falta cambiar la version cada vez si no que haya un sistema en el que puedas decirle a tu mvnrepo el commit en concreto que quieres.

Y como se actualizarian estas dependencias? Pues con CI lo que se haria es hacer build en un mismo workspace de lo que se esta commiteando y de todos los repositorios que dependen de este para ver que no se ha roto nada. Una vez que se hace esto lo unico que falta es actualizar el mvnrepo con la ultima version de la dependencia (basicamente sobreescribir).

Una vez que esta esto funcionando, tienes una manera super sencilla de muchas cosas:

  1. Saber que dependencias exactas (con commit estas usando), es incluso sencillo replicar la build ya que puedes tener un snapshot de ese repo en el momento.
  2. Trabajar en local sin afectar otros proyectos
  3. Una forma sencilla de manejar dependencias incluso con una misma version y no se ha de estar cambiado todo el rato (solo se cambia cuando la API se ve afectada)

Yo tengo muy clarinete que esto es mucho trabajo y que no lo necesito, pero me divierte mucho hacer librerias y herramientas para desarrolladores (en este caso yo como beneficiario). Sinceramente, si escribo aqui es porque mas o menos me ayuda a aclarar lo que tengo en la mente y no se ni siquiera si alguien va a entender una mierda de lo que escribo, yo al menos tenia entendido que era un poquito informativo, tambien es cierto que me suelo explicar como un libro cerrado... pero eso es para otro dia.

Usuarios habituales

  • Lecherito
  • JuAn4k4
  • bLaKnI
  • HeXaN
  • danao
  • claroquesi
  • wdaoajw