PyPRP single-package distribution prototype

Announcements and discussion regarding any projects related to Cyan Worlds' Plasma Engine including (but not limited to) CyanWorlds.com Engine, Drizzle, OfflineKI, PyPRP, and libHSPlasma.

PyPRP single-package distribution prototype

Postby Christian Walther » Sat Mar 28, 2009 2:33 pm

Over in the Is it time for a new PyPRP release? threadzilla,
Christian Walther wrote:
boblishman wrote:Oh ... one little thing ... to whoever compiles the next release ... when you zip up the files, please do NOT have the /scr path in the zip ... as it simply causes unnecessary confusion (for first time installers) ... ;)

Good point. Putting all the Python files at the top level of the archive would make it a bit hard to find the Readme, documentation etc. though. Perhaps giving that folder a more human-readable name, like "scripts", would help already?

Along these lines, I've also wondered whether giving the thing a proper Python package structure would make the heap of loose files a bit more manageable.

I just tried this and found that it works pretty straightforwardly. The result (prototype based on trunk r380) is available at http://svn.guildofwriters.com/pyprp/contrib/CWalther/package/. From there, you just take the PyPRP folder and put it into your .blender/scripts folder. Neat and tidy. Easier to install for users (hopefully - once they found their scripts folder...), and with the added benefit for developers that you can now directly use a Subversion checkout (or a symlink to one).

Developers (and users too), what do you think about this? Should we transform PyPRP like this for the upcoming release?

One caveat is that I'm relying on the fact that Blender also finds the #!BPY scripts to display in its menus in subfolders of the scripts folder. I have not found any documentation about whether that is a supported feature or just an implementation detail that might disappear in a future version.

While I was at it, I removed some imports, and one entire file, that struck me as unused. The simple things I tested still seem to work, but all the from module import * make it a bit messy, so I might have missed something.
Christian Walther
 
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
Location: Switzerland

Re: PyPRP single-package distribution prototype

Postby diafero » Sun Mar 29, 2009 3:40 am

I wonder why you renamed many of the python files and removed the prp_ prefix, but kept it for others? That looks a bit inconsistent. Besides, I always wondered why it is necessary to have all the files in the same folder, so I like the new cleanliness :) . However, what about people upgrading from the current version? They will have to manually remove all the old files... which reminds me that this might also make future upgrades easier as we can just tell people to remove the current PyPRP folder and copy the new one, so that we are sure there are no leftovers of old versions.
I prefer e-mails to "diafero arcor de" (after adding the at and the dot) over PMs.

"Many people's horizon is a circle with a radius of zero. They call it their point of view."

Deep Island Shard | Offline KI
diafero
Deep Island Admin
 
Posts: 2966
Joined: Mon May 05, 2008 5:50 am
Location: Germany

Re: PyPRP single-package distribution prototype

Postby D'Lanor » Sun Mar 29, 2009 6:15 am

diafero, the files that still have the prefix are menu items. Christian explained that he was not sure if those could remain in the subfolder.

I think that removing the prefix just adds extra complications. What if people accidentally install into the main scripts folder anyway because "it used to be that way". Without the prefix it would not be clear to them which files to remove.

Good find about the obsolete prp_GObjects module. It seems that it was renamed to prp_Functions and continued from there.

I would be very careful though with removing imports. Remember that there were import problems and it may just be so that you have removed the workarounds.
"It is in self-limitation that a master first shows himself." - Goethe
User avatar
D'Lanor
 
Posts: 1980
Joined: Sat Sep 29, 2007 4:24 am

Re: PyPRP single-package distribution prototype

Postby Trylon » Sun Mar 29, 2009 6:28 am

I kinda like the simpler filenames in a separate folder, as long as it works....
Makes it easier to get a good overview...
One day I ran through the cleft for the fiftieth time, and found that uru held no peace for me anymore.
User avatar
Trylon
 
Posts: 1446
Joined: Fri Sep 28, 2007 11:08 pm
Location: Gone from Uru

Re: PyPRP single-package distribution prototype

Postby Christian Walther » Sun Mar 29, 2009 8:59 am

diafero wrote:I wonder why you renamed many of the python files and removed the prp_ prefix, but kept it for others? That looks a bit inconsistent.

The prp_ prefix seemed obsolete to me when it's replaced by the PyPRP package name. Previously you wrote import prp_SomeClasses. Now you write import PyPRP.SomeClasses. There is no technical requirement for renaming the files though, we could leave them as they are if you consider that simpler. Then you'd just have to write import PyPRP.prp_SomeClasses. (Now that I think of it - that only applies to the entry point scripts. Within the package, you could continue to say import prp_SomeClasses. Hmm. That would make the changes a bit less invasive, perhaps not a bad idea after all.)

The files I didn't rename are the ones that aren't modules but entry-point scripts. I saw no point to renaming them since they're never referred to in import statements, plus they're clearly distinguished from the modules that way.

diafero wrote:However, what about people upgrading from the current version? They will have to manually remove all the old files...

Yes, but it probably wouldn't be a bad idea to tell them to do that anyway. I don't think any files have been removed since 1.5 (apart from the prp_GObjects.py I removed now), but it can't hurt, and some people may even have old alc_* files lying around from before. Leaving the old modules around should have no adverse effects since from inside the package the module search starts in the package (and from outside the package name has to be specified explicitly), I don't know what Blender does when it has duplicate scripts though.

D'Lanor wrote:What if people accidentally install into the main scripts folder anyway because "it used to be that way". Without the prefix it would not be clear to them which files to remove.

Hmm, good point.

D'Lanor wrote:I would be very careful though with removing imports. Remember that there were import problems and it may just be so that you have removed the workarounds.

I don't remember that (probably because it was before my involvement here). Is there any discussion around about it that I could learn anything from? I see the word "import" appear a few times in the SVN log now, I'll have a look at those.

Thanks for the comments!
Christian Walther
 
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
Location: Switzerland

Re: PyPRP single-package distribution prototype

Postby Christian Walther » Wed Apr 01, 2009 1:22 pm

Here is prototype 2: http://svn.guildofwriters.com/pyprp/contrib/CWalther/package2/

Doing without the file renaming cuts down on the number of text changes drastically. I must say there is a certain appeal to the minimal invasiveness of this solution. 8-) What do you think?

I have asked about the scripts-in-subfolders thing on the Blender forum, and I've also had a look at the Blender source code - the recursive scan is (obviously) deliberate, but it's limited to a depth of 4 folders and a total number of 30 folders. :|

Christian Walther wrote:I see the word "import" appear a few times in the SVN log now, I'll have a look at those.

Most of them were about importing PRP files, not Python modules. The one relevant one I saw was not touched in prototype 1. In prototype 2, the question is moot anyway as I left the imports alone there.
Christian Walther
 
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
Location: Switzerland

Re: PyPRP single-package distribution prototype

Postby Chacal » Wed Apr 01, 2009 8:16 pm

Does this include a fixed import script, such as those done by gpn_milano and Race?
Chacal


"The weak can never forgive. Forgiveness is an attribute of the strong."
-- Mahatma Gandhi
User avatar
Chacal
 
Posts: 2508
Joined: Tue Nov 06, 2007 2:45 pm
Location: Quebec, Canada

Re: PyPRP single-package distribution prototype

Postby D'Lanor » Thu Apr 02, 2009 6:41 am

This is a distribution prototype. It only contains the current trunk. No new features were implemented (nor old broken ones fixed).

The import fix btw is not on the todo list for the release planning.
"It is in self-limitation that a master first shows himself." - Goethe
User avatar
D'Lanor
 
Posts: 1980
Joined: Sat Sep 29, 2007 4:24 am

Re: PyPRP single-package distribution prototype

Postby Christian Walther » Thu Apr 02, 2009 11:51 am

Right. There is a bit of a terminology confusion here - as noted, the term "import" can mean two different things in our context. On the one hand, it means reading an existing PRP file into Blender to edit it or see how it's done. On the other hand, it is used in Python when one Python file refers to another. I am only talking about the latter meaning here, and my proposal has absolutely nothing to do with the former.

I am not aware of a fixed PRP import script (there is no mention of anything import-related in the SVN log since 1.5), and I trust that GPNMilano would have added it to the list along with her other changes if she had made one outside of SVN and considered it ready for release.
Christian Walther
 
Posts: 443
Joined: Sun Jun 08, 2008 3:10 am
Location: Switzerland

Re: PyPRP single-package distribution prototype

Postby D'Lanor » Thu Apr 02, 2009 12:56 pm

I have successfully exported an age using this package. Everything worked as it should.

I also did file comparisons for the export results from the current trunk and package 2. This showed exact matches for each of the age files. I say we go for this method. :)
"It is in self-limitation that a master first shows himself." - Goethe
User avatar
D'Lanor
 
Posts: 1980
Joined: Sat Sep 29, 2007 4:24 am


Return to Plasma Development

Who is online

Users browsing this forum: No registered users and 0 guests

cron