[Sputnik-list] git

[pierre pracht]

Le 6 mars 08 à 00:10, Yuri Takhteyev a écrit :

>> This is what I have done previously (but didn't take time to script  
>> it).
>> But the idea is to invert the process :
>
> The advantage of symlinking, in my opinion, is that it makes it easy
> to mix-and-match rocks from svn and rocks installed from the remote
> repository.

Inverting what is the used as rocks repository didn't change it.

>  E.g., if I made some changes to versium and some changes
> to sputnik, it is important for me to know if the new Sputnik rock
> will _also_ work with the last released versium rock. (If it does,
> for example, I know I can make a new sputnik rock and release it,
> leaving the new versium rock for later.)

Well simply : If release cycle is independent you must have  
independent repository.

If you need to test, you can make a branch. But generally you wouldn't  
release it without committing to master branch.

>  Using your inverted process,
> I will always be using the latest versium and testing sputnik-cvs-1
> against versium-8.02.14 becomes harder.

You can specify a particular version in rocksepc ?
But if it's for testing purpose : The better way is to make a custom  
manifest. A lua script would build  several luarocks_config.lua based  
on possible combination of dependency.

> Does the inverted process have any advantages compared to a script to
> link/unlink rock-like directories into a repository?
>
>> But if rocks get multiple local rocks repository in 0.5, it would
>> obviate the question.
>
> This won't solve the problem, though.

By "obviate" I wanted to say :
No need to run a script. No need to maintain syn-link
Just reference a luarocks_config.lua in your startup script.
Once development environment in place, git pull would keep you up-to- 
date with no extra step.

> The issue is that I want
> luarocks to see some of my svn rocks, but not all of them.

Several solution, make git branch where you:
   -  delete some repertory
   -  edit rocks dependency to use a specific version not the highest  
(cvs-1)
   -  manually edit manifest to remove un-need cvs rocks (can be  
scripted)
And you switch between configuration with git checkout a_branch

For quick test you can editing manifest or rockspec with-out  
committing the change.

And for frequent test configuration, you can make several local git  
clone each using a different branch.

>> I may try it myself :
>> in the git repository
>> README
>> install.sh
>> rocks/alpha/cvs-1/alpha-cvs-1.rockspec
>> rocks/alpha/cvs-1/lua/alphamod/init.lua
>> rocks/beta/....
>
> I would prefer a different default.
>
>    install.sh ~/sputnik -- installs the latest sputnik from the
> remote repository

No need, install.sh is in the git repository : "git pull" and you're  
done
It was how-to automate development environment setup.
The script just need to be launch one time after git clone.

>    link.sh sputnik ~/sputnik -- links the sputnik rock from svn/git
> into the installation

You do it to get : just some of your rocks right ?
See previous comment on branch and luarocks configuration.

>    link_all.sh ~/sputnik -- links _all_ svn/git directories into the
> installation

If local rocks repository isn't inverted, you may need to launch the  
script at each update to take new or modified rocks in account. By  
making git copy a local rocks repository, it pull the manifest with  
him. But developer need to have same version of needed dependency.
Remark : it would be nice to have a development mode in luarocks where  
directory are automatically rescanned (no need of local manifest)

> This way you get what you want by just running two commands instead  
> of one:
>
> install.sh ~/sputnik && link_all.sh ~/sputnik

I agree that's one magical command to rules them all, isn't the way to  
go.
What I was trying to advocate is that git branch and rocks  
configuration offer an other way to go.

> BTW, I have nothing against supporting site-wide installation, but I
> do not want to ever treat it as the default.

The idea of pulling rocks dependency from site-wide, was keep several  
development environment up-to-date with minimal effort :
   - site wide : apt-get or luarocks
   - each project : git pull

- pierre